[LLVMdev] [lld] Atom and its unwind information

[bigcheesegs at gmail.com]

Sent from my iPhone

On Mar 9, 2013, at 1:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:

> On 3/8/2013 5:44 PM, Nick Kledzik wrote:
>> On Mar 8, 2013, at 2:52 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>>> Hi Nick,
>>> 
>>> I was looking at ld64 source code and the atom deals with additional information such as
>>> 
>>> a) UnwindInfo
>> If you are using dwarf unwind info, the dwarf FDE is just another atom (in .eh_frame section).  We'll need a special reference in function atoms to their FDE atom, so that they get dead stripped or coalesced as a group (that is what ld64 does).
> Do you mean typeCode atoms here ? Yes, eh frames are used in ELF. The eh_frame sections have to be first read to make this happen, so that function atoms may point to their respective FDE block.
>>> b) LineInfo
>> This was an experiment in ld64.  At one point we thought it might be nice when erroring out with undefined symbol to give the source file and line number of each use of the undefined symbol.  But that never panned out.
> This might be a good thing to have it in lld too, would be easy to debug things.

My current plan for this is to use the File reference each Atom has to handle printing location info for errors. For example symbols from linker scripts should get caret diags, while object files  should try to use debug info to give caret diags on the original source.

- Michael Spencer

>>> c) SymbolTable inclusion
>> ld64 uses names for anonymous atoms (e.g. all c-string atoms have the name "cstring"). So, then the issue is that some atom names should not go in the symbol table of the output file.  SymbolTable inclusion was a way to manage that.   lld does not have this problem.  Anonymous atoms have no (i.e. empty) names.
> ok.
> 
> Thanks
> 
> Shankar Easwaran
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
>