llvm dev - Mar 2013 - [LLVMdev] [lld] Atom and its unwind information

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
>