[LLVMdev] [lld] need a way to store the original path for atoms

Shankar Easwaran shankarke at gmail.com
Thu Nov 20 09:04:45 PST 2014


On Wed, Nov 19, 2014 at 3:09 PM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On Nov 19, 2014, at 11:26 AM, Shankar Easwaran <shankarke at gmail.com>
> wrote:
>
> > Hi Nick,
> >
> > I need the original path of the files, from where the atoms were parsed.
> >
> > The path for the atoms are completely useless after the round trip pass.
> >
> > This is needed to support linker scripts with the Gnu flavor. I think
> there are more uses too like diagnostics (relocation overflows etc)
> Can you give some examples.   Can whatever the linker scripts needs done,
> be done in a Pass before the round tripping?
>
> The RoundTripping passes are a test suite feature.  They are like running
> "ld -r” first, then linking that one merged .o file.  I’m guessing the
> linker script won’t work on that either (since the original .o filenames
> are lost).
>
> Maybe we just need a —no-round-trip linker option for the test cases that
> need to exercise that part of linker scripts? Or unset
> LLD_RUN_ROUNDTRIP_TEST in the test case.
>

Linker scripts may exclude certain files and certain sections from a
specific output section. EXCLUDE_FILE is one example.

There is also a need for the linker to output the map of the image, for end
user debugging purposes. Files/Sections from input files may be selected in
the output section as well.

Also I was thinking all of the linker script would be handled in the
writer, so the writer would need to know about atoms and the originating
file.

There are many cases of when a relocation could overflow, and producing a
right error message is very much needed for end users.

If we store the originating file as a reference from al atoms it would work
I think.

Shankar Easwaran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141120/46c798d4/attachment.html>


More information about the llvm-dev mailing list