[llvm-commits] [llvm-gcc-4.2] r49253 - /llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
baldrick at free.fr
Mon Apr 7 00:28:56 PDT 2008
> On MacOS there are various parts of the system that need to be able to
> do stack trackbacks at runtime. On x86-32 this is done by
> disassembling the code; for this to work -fenable-fp-elim must be
> turned off. There is a significant performance hit for that, so
> x86-64 does it by looking at Dwarf unwind info. For this to work
> unwind info must be present for all functions. This consideration is
> independent of exceptions.
> The way this is done is that -funwind-tables is implicitly passed to
> all compilations on Darwin x86-64. This has the effect of generating
> the Dwarf traceback tables (what you call frame moves, I believe) in
> all cases. (gcc does not even generate the ".eh=0" elision in leaf
> functions; I think this is a bug in llvm-gcc, although so far it
> hasn't broken anything.) For languages that normally use exceptions, C
> ++ and Obj-C++, -fexceptions is also passed, which additionally
> generates landing pad info.
> Now we can argue about what -funwind-tables and -fexceptions ought to
> mean, it is certainly not clear in the documentation, but I think what
> shipping gcc does with them is a good place to start. If these
> switches behave differently in another environment I suppose we need
> to make their behavior dependent on the environment; I have no
> knowledge of that right now. In what follows I am going to use the
> Darwin x86-64 meanings of these flags.
> -fexceptions does not imply -funwind-tables, although they generate
> some of the same info. The difference is that info produced by virtue
> of -funwind-tables cannot be removed; the OS needs it. It would be OK
> for prune-eh to remove landing pad info. If -fexceptions is present
> and -funwind-tables is not, it is OK to remove both. I believe the
> current behavior matches this.
I think we all agree about what the final effect of -funwind-tables should
be. For me the only question is whether -funwind-tables should be represented
in the IR or not, and if so how. My preference goes to an llc option. This
has the disadvantage that you can't control the -funwind-tables effect on a
per-function basis, but based on the Darwin use case you describe that isn't
needed anyway (nor for Ada).
> Now, how do we reconcile this with what Ada does, and what info do we
> put in the IR to make it happen?
Ada is getting -funwind-tables because it uses -fnon-call-exceptions (which
we don't currently support). I actually don't see why -fnon-call-exceptions
would need -funwind-tables; it will I guess become clear one way or another
when support is added for -fnon-call-exceptions. However Ada also has a stack
traceback facility which uses the dwarf unwinder, and for that to work it
presumably needs -funwind-tables. In short: Ada doesn't seem to need anything
particularly special here, it's basically the same as Darwin.
More information about the llvm-commits