Bug 14187

Summary: gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
Product: binutils Reporter: Mike Frysinger <vapier>
Component: goldAssignee: Cary Coutant <ccoutant>
Status: ASSIGNED ---    
Severity: minor CC: ccoutant, heiko, jeffall, stsp
Priority: P2    
Version: unspecified   
Target Milestone: ---   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=439082
Host: Target:
Build: Last reconfirmed:
Attachments: Patch to fix gold to parse -Ttext, etc., options as hex numbers

Description Mike Frysinger 2012-05-30 22:51:49 UTC
$ echo '' | gcc -x c - -o test.o -c
$ ld test.o -o a.out -Ttext 7C00
ld: fatal error: -Ttext: invalid option value (expected an integer): 7C00
$ ld test.o -o a.out -Ttext 0x7C00
<works>
$ ld test.o -o a.out --section-start=.text=7C00
<works>

this does not match the GNU linker (or its documentation) where it says:
  -Tbss=org
  -Tdata=org
  -Ttext=org
    Same as --section-start, with ".bss", ".data" or ".text" as the sectionname.

  --section-start=sectionname=org
    ...  org must be a single hexadecimal integer; for compatibility with other linkers, you may omit the leading 0x usually associated with hexadecimal values.
Comment 1 jeffall 2012-07-27 07:53:51 UTC
I found the same bug. This makes it so that you cannot compile Grub while gold is installed.
Comment 2 Stas Sergeev 2015-08-24 22:06:53 UTC
Results in a broken build of dosemu.
Comment 3 Cary Coutant 2015-08-25 23:47:58 UTC
We've discussed fixing this before, but we now have legacy scripts that invoke gold with decimal values, and changing it would break them. We could certainly peek at the number and treat it as hex if it has any A-F digits, but that still wouldn't catch options like -Ttext=10000. We could further favor hex over decimal unless it looks like a power of two when treated as decimal (or an integer multiple of some large power of two), but that's straying into dangerously unpredictable territory.

The bottom line is that I don't have a good idea for how to fix this to match the Gnu ld documentation without breaking something.

What's difficult about adding the "0x" so that it works with both linkers?
Comment 4 Mike Frysinger 2015-08-26 02:32:08 UTC
(In reply to Cary Coutant from comment #3)

if something has to break, why not just break gold users ?  the bfd behavior has been around way longer than gold.
Comment 5 Stas Sergeev 2015-08-26 10:29:20 UTC
(In reply to Cary Coutant from comment #3)
> The bottom line is that I don't have a good idea for how to fix this to
> match the Gnu ld documentation without breaking something.
You had to add an option for enabling the gold-specific
extensions. Maybe its still not too late? Who knows...

> What's difficult about adding the "0x" so that it works with both linkers?
It doesn't. Even adding 0x doesn't help because -Ttext
in gold means something completely different than in bfd.
What works in all cases is only
--section-start=.text=0xaddr

Its not something that can't be done.
But you must be aware that gold being used as a drop-in
replacement for ld.bfd results in a broken builds.
It also appears to me that gold doesn't search /usr/local/lib
by default, so even many autoconf scripts fail.
Comment 6 Ian Lance Taylor 2015-08-26 12:41:06 UTC
The difference in -Ttext behaviour between gold and GNU ld is intentional.  The -Ttext option in GNU ld is nearly meaningless when using ELF.  Gold's -Ttext option corresponds to GNU ld's -Ttext-segment option.  The difference in accepted numbers is not.  For some reason nobody ever noticed that ld defaults to hex and gold defaults to decimal.

Yes, this means that gold is not a drop-in linker replacement for all uses.  That is true for several reasons.

As far as I can tell GNU ld does not search /usr/local/lib either, unless configured with a special --with-lib-path option.  In any case, that should be a different bug report.
Comment 7 Stas Sergeev 2015-08-26 13:31:21 UTC
(In reply to Ian Lance Taylor from comment #6)
> The difference in -Ttext behaviour between gold and GNU ld is intentional. 
> The -Ttext option in GNU ld is nearly meaningless when using ELF.  Gold's
> -Ttext option corresponds to GNU ld's -Ttext-segment option.  The difference
> in accepted numbers is not.  For some reason nobody ever noticed that ld
> defaults to hex and gold defaults to decimal.
This bug was filled in 2012, so obviously it was
noticed also before.
IMHO the intentional differences are good, but you
could add a command-line switch to enable them.
For example it seems --section-start actually accepts
the decimal numbers as hex (without requiring 0x), but
-T requires 0x. So you have inconsistencies.

> Yes, this means that gold is not a drop-in linker replacement for all uses. 
> That is true for several reasons.
Its fine as long as you teach the distributions
about this. :) So far at least fedora provides
gold as an "alternative" to ld.bfd, so that you
only do
alternatives --set ld /usr/bin/ld.gold
https://fedoraproject.org/wiki/Features/GoldLinkerDefault
They say:
"The only user-visible change should be link times improve, particularly for very large applications."
I think ubuntu does the same.
So people really think it is a drop-in replacement.
Maybe you can implement an option that will make it
fully compatible? Then fedora will be able to perhaps
run it via some wrapper script that will enable that
compatibility mode? No current users will be affected.

> As far as I can tell GNU ld does not search /usr/local/lib either, unless
> configured with a special --with-lib-path option.  In any case, that should
> be a different bug report.
OK, I'll report that to fedora then, thanks.
Comment 8 Mike Frysinger 2015-08-26 17:08:26 UTC
it goes back even further ... this report was created as a result of earlier reports dating back to at least Oct 2011:
https://savannah.gnu.org/bugs/?34539
Comment 9 Ian Lance Taylor 2015-08-27 03:27:56 UTC
Not that it matters much, but gold was first released in 2008, so when I say "nobody noticed" I meant for those first four or so years.
Comment 10 Mike Frysinger 2015-08-27 04:01:56 UTC
(In reply to Ian Lance Taylor from comment #9)

sure, it was first released in binutils-2.19 which was ~Oct 2008 (3 years before the grub report), but i don't think people generally started using it until later: it required distros to update, and i think we can agree that it was another release or two before it could be used as more of a drop in vs project specific one-offs.
Gentoo: May 2009
Fedora: Nov 2009 (F13)

i don't have an opinion on the various behaviors of -T, but i think the number parsing should be the same, and gold should be the one to change (even though it kind of sucks).  accepting addresses in decimal is just weird tbh.
Comment 11 Cary Coutant 2015-08-28 03:16:51 UTC
Created attachment 8557 [details]
Patch to fix gold to parse -Ttext, etc., options as hex numbers

The attached patch changes gold to parse the -Ttext, etc., values
as hex numbers, but will print a warning if it sees a value that
looks more like a decimal number (in order to catch legacy uses).
Comment 12 Cary Coutant 2015-08-28 03:25:37 UTC
> sure, it was first released in binutils-2.19 which was ~Oct 2008 (3 years
> before the grub report), but i don't think people generally started using it
> until later: it required distros to update, and i think we can agree that it
> was another release or two before it could be used as more of a drop in vs
> project specific one-offs.
> Gentoo: May 2009
> Fedora: Nov 2009 (F13)
> 
> i don't have an opinion on the various behaviors of -T, but i think the
> number parsing should be the same, and gold should be the one to change
> (even though it kind of sucks).  accepting addresses in decimal is just
> weird tbh.

If I remember correctly, there were some legacy uses of gold within Google
that used decimal parameters; those are the users I was concerned about.

Maybe accepting addresses in decimal is weird, but I think it's weirder
that only a few options default to hex. For example, -z max-page-size,
-z stack-size, --image-base (PE) take a (default) decimal value.

These options also don't seem to have a way to specify decimal or octal.
That makes them inconsistent with all other ld options that take a value.
Comment 13 Stas Sergeev 2015-08-28 12:45:31 UTC
(In reply to Cary Coutant from comment #11)
> Created attachment 8557 [details]
> Patch to fix gold to parse -Ttext, etc., options as hex numbers
> The attached patch changes gold to parse the -Ttext, etc., values
> as hex numbers, but will print a warning if it sees a value that
> looks more like a decimal number (in order to catch legacy uses).
Please don't.
-Ttext in gold means entirely different thing, 0x won't help.
Don't break you current users without fixing anything at all.
Comment 14 Cary Coutant 2015-09-14 23:22:53 UTC
(In reply to Stas Sergeev from comment #13)
> (In reply to Cary Coutant from comment #11)
> > Created attachment 8557 [details]
> > Patch to fix gold to parse -Ttext, etc., options as hex numbers
> > The attached patch changes gold to parse the -Ttext, etc., values
> > as hex numbers, but will print a warning if it sees a value that
> > looks more like a decimal number (in order to catch legacy uses).
> Please don't.
> -Ttext in gold means entirely different thing, 0x won't help.
> Don't break you current users without fixing anything at all.

I don't see why we should leave this bug unfixed just because we don't match Gnu ld's behavior for -Ttext.

The original report was about accepting hex numbers without the 0x, and had nothing to do with what you're talking about.

Ian has already explained why Gnu ld's -Ttext is useless on ELF targets, and I did a little historical research to find that the -Ttext option on several other linkers is described it as setting the address of the text *segment*, which is what gold implements.

I think if there's anyone out there using -Ttext with a decimal value, the proposed patch will probably catch it and warn them of the change, assuming a high likelihood that they're using a multiple of a power of two. It's probably more likely that everyone is already spelling it with a 0x.
Comment 15 Stas Sergeev 2015-09-15 09:08:11 UTC
(In reply to Cary Coutant from comment #14)
> I don't see why we should leave this bug unfixed just because we don't match
> Gnu ld's behavior for -Ttext.
> 
> The original report was about accepting hex numbers without the 0x, and had
> nothing to do with what you're talking about.
Ah, if your patch can fix the problem for other
people here, then fine. My expectation is that it
just won't. It doesn't fix anything for me for sure.

Can someone in this thread confirm such a change
can fix anything at all, even despite the other
incompatibilities of the same -Ttext option?
Comment 16 Stas Sergeev 2015-09-15 15:16:28 UTC
(In reply to Cary Coutant from comment #14)
> The original report was about accepting hex numbers without the 0x, and had
> nothing to do with what you're talking about.
Note that the original report was explicitly about -Ttext.
Your change will likely remove the mentioned error
message, but people will start wondering why it still
doesn't work. So you can turn an explicit error msg into
a silent breakage.