From: Ian Lance Taylor <iant@google.com>
To: Roland McGrath <roland@hack.frob.com>
Cc: Binutils <binutils@sourceware.org>, Roland McGrath <mcgrathr@google.com>
Subject: Re: gold regression vs BFD ld: __ehdr_start
Date: Mon, 31 Mar 2014 19:19:00 -0000 [thread overview]
Message-ID: <CAKOQZ8x2Aj3reAZKyEAAKKjcFFTu7KZY01WwXCHiOD0WLQC=_g@mail.gmail.com> (raw)
In-Reply-To: <20140330011513.D6435744AE@topped-with-meat.com>
On Sat, Mar 29, 2014 at 6:15 PM, Roland McGrath <roland@hack.frob.com> wrote:
> With trunk on x86_64-linux-gnu:
>
> $ cat foo.s
> .text
> .globl _start
> _start:
> lea __ehdr_start(%rip), %r11
> $ ./gas/as-new -o foo.o foo.s
> $ ./ld/ld-new -shared -o foo.so foo.o
> $ readelf -rs foo.so
>
> There are no relocations in this file.
>
> Symbol table '.dynsym' contains 6 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 00000000000001c1 0 SECTION LOCAL DEFAULT 4
> 2: 00000000000001c1 0 NOTYPE GLOBAL DEFAULT 4 _start
> 3: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 __bss_start
> 4: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _edata
> 5: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _end
>
> Symbol table '.symtab' contains 14 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 00000000000000e8 0 SECTION LOCAL DEFAULT 1
> 2: 0000000000000118 0 SECTION LOCAL DEFAULT 2
> 3: 00000000000001a8 0 SECTION LOCAL DEFAULT 3
> 4: 00000000000001c1 0 SECTION LOCAL DEFAULT 4
> 5: 00000000000001c8 0 SECTION LOCAL DEFAULT 5
> 6: 00000000002001c8 0 SECTION LOCAL DEFAULT 6
> 7: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 __ehdr_start
> 8: 00000000002001c8 0 OBJECT LOCAL DEFAULT 6 _DYNAMIC
> 9: 0000000000000000 0 OBJECT LOCAL DEFAULT 6 _GLOBAL_OFFSET_TABLE_
> 10: 00000000000001c1 0 NOTYPE GLOBAL DEFAULT 4 _start
> 11: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 __bss_start
> 12: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _edata
> 13: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _end
> $ ./gold/ld-new -shared -o foo.so foo.o
> ./gold/ld-new: error: foo.o: requires dynamic R_X86_64_PC32 reloc against '__ehdr_start' which may overflow at runtime; recompile with -fPIC
> [Exit 1]
> $
>
> I think when __ehdr_start was first added to BFD ld, it may have behaved
> this way too. But it works properly now. The key issue is that when the
> __ehdr_start symbol is in its indeterminate state, it still needs to be
> understood to be STV_HIDDEN so that it doesn't generate dynamic relocs.
> When it is eventually found that it can be defined and it is--a decision
> that can only be made after layout--then it will be defined as STV_HIDDEN,
> so it should always get static resolution. If at the end of the way it
> can't be defined (layout with no readable segment covering the file
> headers), then it is probably fine to get an error rather than generating
> the dynamic relocs that would be normal for any random undefined
> symbol--albeit, that is a regression relative to pre-2.23 linkers when
> users happen to use this once mundane, now magic symbol name. (I'm not
> sure any more if 2.24/trunk BFD ld has that regression against its own
> pre-2.23 behavior or not.)
>
> I think what has to happen is something analogous to what BFD ld does now:
> Add the symbol early on in an undefined or indeterminate state, and then
> define it (or don't) later on. It's not very clear to me how to do that
> correctly in gold. It would seem clearest if it can be done in
> define_standard_symbols. But I don't know what Layout::finalize (where
> it's created now) should do to find it and adjust it to point at the right
> segment. I also don't know how either case would interact with a user
> defining (in input or script) this symbol name himself, in which case (IIRC
> the BFD ld behavior) the user's symbol should be wholly unmolested (but it
> might be that BFD ld uses the user's value but marks it STV_HIDDEN
> anyway--I'm not sure).
I don't know why __ehdr_start is defined in Layout::finalize. As you
suggest, it should be defined by define_standard_symbols instead,
setting the only_if_ref field to true. If necessary, Layout::finalize
can adjust the symbol value using init_output_segment, but only if the
symbol is marked as predefined. Layout::finalize can simply look up
the symbol by name.
Ian
next prev parent reply other threads:[~2014-03-31 19:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-30 1:15 Roland McGrath
2014-03-31 19:19 ` Ian Lance Taylor [this message]
2014-03-31 21:03 ` Cary Coutant
2014-03-31 21:07 ` Roland McGrath
2014-03-31 21:18 ` Cary Coutant
2014-03-31 21:27 ` Roland McGrath
2014-03-31 22:19 ` Cary Coutant
2014-04-01 16:34 ` Roland McGrath
2014-04-01 21:50 ` Cary Coutant
2014-04-01 22:28 ` Cary Coutant
2014-04-01 22:50 ` Roland McGrath
2014-04-01 22:59 ` Cary Coutant
2014-04-01 23:02 ` Cary Coutant
2014-04-03 17:27 ` Roland McGrath
2014-04-23 21:08 ` Roland McGrath
2014-04-23 21:45 ` Cary Coutant
2014-04-23 22:03 ` Roland McGrath
2014-05-06 21:53 ` Cary Coutant
2014-05-06 21:54 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKOQZ8x2Aj3reAZKyEAAKKjcFFTu7KZY01WwXCHiOD0WLQC=_g@mail.gmail.com' \
--to=iant@google.com \
--cc=binutils@sourceware.org \
--cc=mcgrathr@google.com \
--cc=roland@hack.frob.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).