<div dir="ltr">I've modified the linker script parser to support ABSOLUTE on the right hand side, I can upload the patch to Phabricator.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 8, 2017 at 6:21 PM Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Wed, Mar 8, 2017 at 3:45 PM, Petr Hosek <span dir="ltr" class="gmail_msg"><<a href="mailto:phosek@google.com" class="gmail_msg" target="_blank">phosek@google.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Mar 8, 2017 at 10:52 AM Cary Coutant <<a href="mailto:ccoutant@gmail.com" class="gmail_msg" target="_blank">ccoutant@gmail.com</a>> wrote:</div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No, symbols in an ET_EXEC or ET_DYN object always have<br class="m_-1901857281370272241m_7959679570031656314gmail_msg gmail_msg">
already-relocated values. The section index is irrelevant other than<br class="m_-1901857281370272241m_7959679570031656314gmail_msg gmail_msg">
to indicate that the symbol is not absolute or undefined. That's the<br class="m_-1901857281370272241m_7959679570031656314gmail_msg gmail_msg">
point of the paragraph I quoted from the end of the symbol table<br class="m_-1901857281370272241m_7959679570031656314gmail_msg gmail_msg">
chapter from the ELF spec. In gold, I try to find a section that<br class="m_-1901857281370272241m_7959679570031656314gmail_msg gmail_msg">
belongs to the segment that the symbol is associated with, but setting<br class="m_-1901857281370272241m_7959679570031656314gmail_msg gmail_msg">
st_shndx to 1 would be just as effective.<br class="m_-1901857281370272241m_7959679570031656314gmail_msg gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">I think this is an issue in LLD. I started experimenting with the solution proposed by Peter which is to replace that linker script with:<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">PROVIDE_HIDDEN(_base = ADDR(.text) - ABSOLUTE(ADDR(.text)));</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Does this even parse? I believe LLD accepts ABSOLUTE() only immediately after an assignment operator.</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">In LLD, this symbol would be processed as a synthetic symbol with value 0 and .text section, which is correct. The problem is that LLD assumes that all synthetic symbols are section relative, so when emitting that symbol, LLD would adjust its address by the address of .text, so the final value is going to be whatever the .text address is rather than image base.</div></div></div>
</blockquote></div></div></div></blockquote></div>