| Summary: | gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Mike Frysinger <vapier> |
| Component: | gold | Assignee: | Cary Coutant <ccoutant> |
| Status: | ASSIGNED --- | ||
| Severity: | minor | CC: | ccoutant, devurandom, 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 | ||
I found the same bug. This makes it so that you cannot compile Grub while gold is installed. Results in a broken build of dosemu. 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? (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. (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. 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. (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. 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 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. (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. 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).
> 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.
(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. (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. (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? (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. |
$ 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.