[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

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

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