D52985/D57677 added a .gcc_except_table workaround, but the new behavior
doesn't match GNU assembler.
void foo(); int bar() { foo(); try { throw 1; } catch (int) { return 1; } return 0; } clang --target=mipsel-linux-gnu -mmicromips -S a.cc mipsel-linux-gnu-gcc -mmicromips -c a.s -o gnu.o .uleb128 ($cst_end0)-($cst_begin0) // bit 0 is not forced to 1 .uleb128 ($func_begin0)-($func_begin0) // bit 0 is not forced to 1
I have inspected .gcc_except_table output by mipsel-linux-gnu-gcc -mmicromips -c a.cc.
The .uleb128 values are not forced to set the least significant bit.
In addition, D57677's adjustment (even->odd) to CodeGen/Mips/micromips-b-range.ll is wrong.
PC-relative .long func - . values will differ from GNU assembler as well.
The original intention of D52985 seems unclear to me. I think whatever
goal it wants to achieve should be moved to an upper layer.
This isMicroMips special case has caused problems to fix MCAssembler::relaxLEB to use evaluateAsAbsolute instead of evaluateKnownAbsolute,
which is needed to proper support R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128.
I left a comment to https://reviews.llvm.org/D57677#4594051 . I am now more certain that the micromips .gcc_except_table is wrong and harmful and I am going to land this revert.
Nobody has noticed an issue likely because micromips support is quite poor in llvm.