[LLVMdev] LLVM creates unterminated ELF .eh_frame sections
rafael.espindola at gmail.com
Tue Apr 30 21:33:52 PDT 2013
>> I first tried to compensate for that in MCJIT by adding those 4 bytes.
>> That works for Linux, but not for OS X where __register_frame takes a
>> single FDE at a time. I have an incomplete wip patch if you are
> On BSD __register_frame also takes a single argument and therefore needs
> terminating zero.
> I also have a simple patch for this: adding Streamer.EmitIntValue(0, 4); at
> the end of MCDwarfFrameEmitter::Emit in lib/MC/MCDwarf.cpp fixed the issue
> for me.
> Somebody needs to check this or similar in.
No. I think you misunderstood me. On Linux __register_frame takes a
single argument: a pointer to the start of the .eh_frame section. How
can it find the end? Because crtendS.o is linked in and it has an
.eh_frame section with zeros:
$ readelf -x .eh_frame /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtendS.o
Hex dump of section '.eh_frame':
0x00000000 00000000 ....
Adding these zeros to the end of every CFI (or even every translation
unit) would be wrong. This cannot be fixed in the compiler proper. It
might be a bug in the driver not passing a correct tail object like
crtendS.o in your OS.
What is different on OS X (but not really relevant here now that I
know it is not the MCJIT issue) is that __register_frame there takes a
single FDE as an argument.
More information about the llvm-dev