[llvm-commits] [llvm] r46088 - in /llvm/trunk: include/llvm/CodeGen/MachineModuleInfo.h lib/CodeGen/DwarfWriter.cpp lib/CodeGen/MachineModuleInfo.cpp

Devang Patel dpatel at apple.com
Sun Jan 20 09:23:47 PST 2008


On Jan 18, 2008, at 6:12 PM, Dale Johannesen wrote:

>
> On Jan 17, 2008, at 1:31 AM, Duncan Sands wrote:
>
>> Hi Dale,
>>
>>> Do not mark EH tables no-dead-strip unless the
>>> associated function is so marked.
>>
>> can you please explain what this means?
>
> Dead stripping is a linktime optimization, where code not reachable
> from main is removed.

This optimization is done by Darwin linker and it is not related to  
LLVM LTO. When LLVM LTO is used, LTO takes advantage of this linker  
optimization but that is orthogonal to this bug.

>  Functions can be marked no-dead-strip
> (__attribute__((used)) in gcc) to prevent the linker from removing
> them, even though they aren't obviously reachable.
>
> On Darwin the EH tables do not have a magic association with the
> corresponding function; they're treated as separate symbols by the
> linker (and there are subtle differences between the Tiger and Leopard
> linkers, just to make things more interesting).   Generally, storage
> class and visibility have to match between function and table so the
> linker does not pick a function/table combination from different files
> (which doesn't work).   So, if a function is marked no-dead-strip, its
> table must be also.  The bug here was that tables were being marked  
> no-
> dead-strip when the function was not; since the tables have references
> to the functions, this resulted in the function being kept as well;
> and if the functions have references to undefined externals that don't
> exist anywhere, you get a linktime (or, in some circumstances, dynamic
> linktime) crash.  (If I ran the universe, people with dead code that
> calls undefined externals would have to clean up their code.   I  
> don't.)
>
>> And is
>> there a testcase?
>
> Not now.  This only affects Darwin (and now SPU, but I'm pretty sure
> this is the right thing there too), fwiw.
>
>> Thanks!
>>
>> D.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list