llvm dev - Nov 2014 - [LLVMdev] [lld] need a way to store the original path for atoms

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)

I was planning to add a patch so that the native writer, stores the
original path for atoms

Another way to fix the problem is to I can also have a lld core reference
that points to the path information(archive files will need to record the
member and the path of the archive file).

Let me know your inputs.

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

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.

-Nick
> 
> I was planning to add a patch so that the native writer, stores the
original path for atoms
> 
> Another way to fix the problem is to I can also have a lld core reference
that points to the path information(archive files will need to record the member
and the path of the archive file).

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>