[llvm-dev] GPL Software
jacob navia via llvm-dev
llvm-dev at lists.llvm.org
Tue Aug 25 12:59:41 PDT 2015
Le 25/08/2015 20:39, Renato Golin a écrit :
> I'm also interested in knowing what you did. I think most people here
> would be glad to know your peril and how you solved it.
C++ code calls
JITted C code, compiled and linked on the fly tha calls
C++ code that throws
The throw must pass through the JITted code to arrive at the catch at
So, the JIT must generate and install the CIE/FDE DWARF4 debug info to
inform the stack unwinding virtual machine how to do it.
1) Do not read the DWARF docs. They give you a general idea but nobody
2) Do not try to *understand* anything. It is hopeless and you will just
lose your time.
3) Try to generate EXACTLY what llvm is generating.
So, I extracted the __eh_frame section from a simple C program.
otool -s __TEXT __eh_frame hello.o
I figure out from the hexadecimal dump where the CIE lies. Then, I
generate exactly the same.
Then, generate the FDEs for each function. Again, use the dump of the
__eh_frame section as a guide but add your own virtual machine
instructions. Of course do not copy blindly what llvm generates since
some fields like length, etc mst be changed!
Then the problem arises:
You have to inform the running program that a new piece of code has ben
JITted and add the eh_frame info dynamically. That is the question I
asked here a month ago.
Since there were no answers, I tried the code that uses the
as specified in some Apple's program source.
Do not do that. It will just never work, it returns always zero.
Then I tried to use what I use on Linux:
void __register_frame_info_table_bases (void *begin, struct object *ob,
void *tbase, void *dbase);
This function requires a different format than register_frame_info,
quite difficult to generate.
Do not bother, it doesn't work, even if it is advertised as "working in
OS X now".
Then I tried to use
register_frame_info with yet another format. Didn't work either.
Desperate to know WHY it wasn't working I followed the machine on
assembly, instruction by instruction until I got there. The reason was
obvious: That function consists of just...
a return statement. Nothing more. It is decoy to avoid giving you a
Then I was TRULY desperate and asked Apple. That worked. The friendly
people at the Apple groups told me to look into the code of the dynamic
loader that does exactly what I was trying to do OF COURSE!
I compiled that. Do not use the xcode project coming with the software
because I got incredible strange debugger problems and could not debug
it. Using a simple Makefile works.
Then, I could follow ALL the process of calling __register_frame(); and
that function works. It expects an FDE (not a CIE as I thought) but
reads the CIE using the CIE pointer in the given FDE for each FDE.
Now, the throw of the C++ code below my JIT code is catched by the C++
This is just a quick description. I do not speak about all the wrong
starts, the dead ends, the sheer frustration at the lack of docs, etc.
This is the result of this part of the compiler being very complex by
design (DWARF is incredibly complex), and a total lack of documentation.
For instance the entry for __register_frame_info in GNU docs is just:
On top of this, Apple has modified the DWARF specs to compress the
information, and it uses a public domain library (libunwind) that has
been heavily modified. If this isn't a MESS I do not know what a mess is.
Anyway, I got there in just a month of work. I am getting better, under
linux it took me three months, but that was the first time.
P.S. Sorry for the message about GNU software. I was mad at you, but
actually is not your fault. You have also your share of hard work. I
suppose that at a certain level of complexity there are always VERY FEW
people that know anything, and you have to figure it out yourself
without any help.
More information about the llvm-dev