[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #2 from Stas Sergeev --- Results in a broken build of dosemu. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #5 from Stas Sergeev --- (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. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #7 from Stas Sergeev --- (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. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #13 from Stas Sergeev --- (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. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #15 from Stas Sergeev --- (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? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #16 from Stas Sergeev --- (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. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/29761] New: relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 Bug ID: 29761 Summary: relocatable linking loses some symbols Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 14439 --> https://sourceware.org/bugzilla/attachment.cgi?id=14439&action=edit test case Attached is an automated test-case. Run test.sh to see the symbol is lost. Run test.sh lld to run the same test via lld, which works correctly. gold also works correctly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #4 from Stas Sergeev --- Thanks, that was quick! Interestingly, the symbol was not really excluded. It was still present in an nm output, but without a name. This makes me wonder, now, in case of a non-relocatable link when such symbol should actually be excluded, will it be excluded properly or would it just lost its name, as was seen here? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #6 from Stas Sergeev --- Yeah that code looks strange, and if I had to guess (w/o ever looking into the actual code), I'd say that just this is enough: if (name == NULL || *name == '\0') disable_output_symbol_name(); as it doesn't actually remove the symbol. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] New: SIGSEGV when linking PE
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 Bug ID: 29807 Summary: SIGSEGV when linking PE Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 14462 --> https://sourceware.org/bugzilla/attachment.cgi?id=14462&action=edit test case Attached is a test-case. Shell script runs ld -mi386pe crt0.o libc.a and that sigsegves. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #1 from Stas Sergeev --- JFYI, I have created that object with objcopy from elf. Not sure what is fuzzed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #3 from Stas Sergeev --- Created attachment 14464 --> https://sourceware.org/bugzilla/attachment.cgi?id=14464&action=edit elf test-case Here is the original objects which I converted to PE. Without conversion to PE, the link succeeds, as can be seen by running test.sh from that archive. However! With nm you can see that one symbol have lost its name again, as was the case in a nearby report about relocatable linking. But this time the linking is not relocatable. So I suspect we need to re-open also that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #7 from Stas Sergeev --- Created attachment 14465 --> https://sourceware.org/bugzilla/attachment.cgi?id=14465&action=edit new test-case Here is a new test-case that shows the symbol name drop even w/o relocatable linking. Please check on a new/patched binutils, as I suspect we need to re-open this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #8 from Stas Sergeev --- Please run `nm a.out | grep 2000` after test.sh. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #4 from Stas Sergeev --- Created attachment 14466 --> https://sourceware.org/bugzilla/attachment.cgi?id=14466&action=edit reduced test-case I reduced the test-case to bare minimum. No fancy binary blobs this time! Just run "make" and it will build an example to segfault. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 Stas Sergeev changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Stas Sergeev --- Lets reopen to not forget the re-check. Please close if the new test-case is also fixed by the prev patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #5 from Stas Sergeev --- I suggest removing "fuzzed" from the description as it suggests I did something malicious to the objects. Last test-case shows I didn't, as it generates an objects from source. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29808] New: --no-allow-shlib-undefined seems to be ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=29808
Bug ID: 29808
Summary: --no-allow-shlib-undefined seems to be ignored
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
void foo(void);
int main()
{
foo();
return 0;
}
$ gcc -shared -Wl,--no-allow-shlib-undefined -o libmain.so main.c
produces no error.
Things like --no-undefined seems to work
also for shlibs though.
If this is a documentation error, please fix
the documentation. :)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29809] New: strip strips too much from relocatable objects
https://sourceware.org/bugzilla/show_bug.cgi?id=29809 Bug ID: 29809 Summary: strip strips too much from relocatable objects Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 14467 --> https://sourceware.org/bugzilla/attachment.cgi?id=14467&action=edit test case Attached is a simple test-case. strip removes "main" so linking then fails. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29810] New: objcopy to pe-i386 corrupts relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=29810 Bug ID: 29810 Summary: objcopy to pe-i386 corrupts relocations Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 14468 --> https://sourceware.org/bugzilla/attachment.cgi?id=14468&action=edit test case Attached test-case shows that the program can be compiled correctly directly to PE - use "make good" for that. To demonstrate the bug, use "make bad" - in that case an extra step is added, such as the source is compiled to elf first and then converted to PE with objcopy. The test-case manages to avoid the linker crash https://sourceware.org/bugzilla/show_bug.cgi?id=29807 by using strip, and it manages to avoid https://sourceware.org/bugzilla/show_bug.cgi?id=29809 by using "strip --strip-debug". At the end, linking fails complaining to the "0-bit reloc in dll": i686-w64-mingw32-gcc hel.o prnt.o -o bad.exe /usr/bin/i686-w64-mingw32-ld: error: 0-bit reloc in dll /usr/bin/i686-w64-mingw32-ld: error: 0-bit reloc in dll /usr/bin/i686-w64-mingw32-ld: error: 0-bit reloc in dll /usr/bin/i686-w64-mingw32-ld: error: 0-bit reloc in dll collect2: error: ld returned 1 exit status make: *** [Makefile:14: bad.exe] Error 1 The test case uses mingw for convenience, but the same error happens invoking ld directly: $ ld -mi386pe hel.o prnt.o -o bad.exe ld: error: 0-bit reloc in dll ld: error: 0-bit reloc in dll ld: error: 0-bit reloc in dll ld: error: 0-bit reloc in dll -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29809] strip strips too much from relocatable objects
https://sourceware.org/bugzilla/show_bug.cgi?id=29809 --- Comment #2 from Stas Sergeev --- (In reply to Alan Modra from comment #1) > Don't strip relocatable object files if you > need access to their symbols! Are the resulting objects useful for anything at all? Is the intentional behavior documented? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #11 from Stas Sergeev --- (In reply to H.J. Lu from comment #10) > Linker removed the local symbol _CRT0_EH_FRAME_BEGIN_ since its section, > .eh_frame, > was unused and removed. But why it only removed the name of a symbol? Can it remove the symbol properly? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #14 from Stas Sergeev --- Thanks, so with this fix I suppose the symbol in the last test-case no longer loses its name. But is it really removed as it should be per comment #10? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] objcopy converts ELF relocatable object to PE that cause a ld segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #8 from Stas Sergeev --- If only objcopy could also be fixed... Is there now any other way to create PE, rather than to install mingw? Seems like w/o working objcopy, one needs to install mingw just for that? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30063] New: inadequate error messages on wrong input file
https://sourceware.org/bugzilla/show_bug.cgi?id=30063 Bug ID: 30063 Summary: inadequate error messages on wrong input file Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 14644 --> https://sourceware.org/bugzilla/attachment.cgi?id=14644&action=edit test case $ ld -melf_i386 -shared --whole-archive libc.a (libc.a is from attachment) This generates many "undefined reference" errors, which is weird with "-shared" and cannot be suppressed with "-z undefs" or any other options. Both lld and gold produce the right message: "ld.lld: error: libc.a(acos.O): not an ELF file" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30063] inadequate error messages on wrong input file
https://sourceware.org/bugzilla/show_bug.cgi?id=30063 --- Comment #2 from Stas Sergeev --- Thanks! May I guess that the fix went to the older branches as a back-port, but wasn't initially in them? Do you know in what version it initially went in, not as a back-port? Or maybe you know the exact commit that I should ask the distro to apply? If you don't have such info, then feel free to close. This bug is not urgent (its only about a bad diagnostic), so if there is no concrete patch to back-port, then I'll live without it quite well. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30063] inadequate error messages on wrong input file
https://sourceware.org/bugzilla/show_bug.cgi?id=30063 --- Comment #4 from Stas Sergeev --- Your @redhat address indicates you may well raise it to fedora? :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30063] inadequate error messages on wrong input file
https://sourceware.org/bugzilla/show_bug.cgi?id=30063 --- Comment #7 from Stas Sergeev --- (In reply to H.J. Lu from comment #6) > The input files are i386 COFF files. If the linker supports i386 COFF, you > will > get the undefined symbol error for i386 COFF input: Thanks for an update. But I explicitly said "-melf_i386", so is it good to try to "support COFF" here? Also those undefined symbols are weird for -shared and unsuppressible by any option. So is it still a bug then? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30063] inadequate error messages on wrong input file
https://sourceware.org/bugzilla/show_bug.cgi?id=30063 Stas Sergeev changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|NOTABUG |--- --- Comment #8 from Stas Sergeev --- So re-opening per HJ's update. Obviously its not fixed, just depends on a build options. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #4 from Stas Sergeev --- Would it be possible to get the pre-built binutils with that patch for testing? The problem was reported to me which seems to be this one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #5 from Stas Sergeev --- Created attachment 14836 --> https://sourceware.org/bugzilla/attachment.cgi?id=14836&action=edit test case This test-case ends with ld: error: source object obj2.o has EABI version 5, but target out.o has EABI version 0 ld: failed to merge target specific data of file obj2.o make: *** [Makefile:4: out.o] Error 1 Nick, could you please check if your patch fixes this? Seems a bit easier than to convince people to test the patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #7 from Stas Sergeev --- (In reply to Nick Clifton from comment #6) > It doesn't. :-( But you can fix the problem by rearranging the order of the > object files on the link command line: Thanks, waiting for the test results from client. In a mean time, if your patch doesn't fix that, then will you provide another patch? Or is this not a bug, or is this not the same bug that was reported here, or what is the status? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30063] inadequate error messages on wrong input file
https://sourceware.org/bugzilla/show_bug.cgi?id=30063 --- Comment #10 from Stas Sergeev --- (In reply to Alan Modra from comment #9) > No, there isn't a bug here that needs fixing. Linking input object files to > other output formats is something that ld can do in only very limited > circumstances and certainly not in the case you are trying. But there was no asking of that. I only wanted an adequate error message. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] New: conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 Bug ID: 30561 Summary: conversion from binary to PE broken Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- $ objcopy -I binary -O pe-x86-64 /etc/resolv.conf tst.o $ file tst.o tst.o: data Same for pe-i386. Looking into the resulting file, it seems to contain the needed symbols, like _binary__etc_resolv_conf_start _binary__etc_resolv_conf_end _binary__etc_resolv_conf_size. It seems like the PE header is wrong. When converting from something else than a binary, or when converting a binary to elf, then things work as expected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #2 from Stas Sergeev --- Hi Nick, thanks for a suggestion. Its not as simple, at the very minimum I'll need to generate with some script such .S files, so that they provide the needed symbols, like _binary__etc_resolv_conf_start _binary__etc_resolv_conf_end _binary__etc_resolv_conf_size. I know how to do that. Still would you mind clarifying why "There is just not enough information in the input format to enable a proper conversion"? If this is true, then I'll just write the script. If not true - I would expect the bugfix is needed. :) Please note that converting the same to ELF works well. In this particular case it seems likely the PE header got messed up. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #4 from Stas Sergeev --- (In reply to Nick Clifton from comment #3) > Well for example, objcopy has no way of determining whether the input binary > contains code, data, or something else. So it is not at all obvious which > section(s) should be used to contain the input. AFAIK you can use --rename-section if you don't want to have the default .data. man page even has an example of how to do this. > Plus there is nothing to > indicate if there are any alignment requirements for the input, I think --set-section-alignment can be used to set an alignment of a desired section. Sure thing with incbin you can do lots of fancy tricks, define more symbols than objcopy would, and so on. But objcopy seems to cover most of the basic needs. > But my feeling is that fixing it is a very low priority, at least at the > moment. It breaks under cygwin (not only under cygwin), where PE is a default. So while a very minor problem under linux, its quite a problem under windows. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #5 from Stas Sergeev --- OK, I use the work-around you suggested. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] New: [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Bug ID: 30970 Summary: [rfe] please include HPA segelf work Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Hi guys. I've recently discovered this binutils fork by HPA: https://git.syslinux.org/users/hpa/segelf/binutils.git/ Which implements this elf extension proposal: https://git.syslinux.org/users/hpa/segelf/abi.git/tree/segelf.txt I've also found his nasm elf16 fork: https://github.com/netwide-assembler/nasm/tree/elf16 I built these things locally and ported my project to this segelf scheme without a slightest issue: https://github.com/dosemu2/fdpp/issues/172#issuecomment-1760271090 So its an absolutely marvelous piece of code, but unfortunately HPA has lost an interest to it many years ago. How feasible would it be for binutils gurus to take it over and upstream? I myself can't tell if something is missing in his impl. But it works for me perfectly well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||hpa at zytor dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30974] New: DEFINED() always evaluates to 0
https://sourceware.org/bugzilla/show_bug.cgi?id=30974 Bug ID: 30974 Summary: DEFINED() always evaluates to 0 Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 15176 --> https://sourceware.org/bugzilla/attachment.cgi?id=15176&action=edit test case Please run ./test.sh from the attached archive. It uses --defsym to define the symbol, and DEFINED() directive in linker script to check for that. I implemented a kind of "assert" in a linker script, just for the sake of this test-case. If DEFINED() returns 0, then the output will be: ld: section .ptext LMA [0074,008e] overlaps section .ltext LMA [,0653] It would really help if you implement ASSERT() natively, but this is another story. This test-case works properly with ld.lld but fails with GNU ld. It seems, DEFINED() returns 0 no matter what. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #9 from Stas Sergeev --- The status of this bug is "WAITING". Waiting for what? I provided a test-case and it was confirmed, so please update the status? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #11 from Stas Sergeev --- (In reply to Nick Clifton from comment #10) > The results of the tests that you said you were running in comment #7. The results were absolutely positive. The suggested work-around works as expected. But why to wait for them? The fact that the work-around worked, is not helpful in fixing the bug itself. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #13 from Stas Sergeev --- (In reply to cvs-com...@gcc.gnu.org from comment #12) > The master branch has been updated by Nick Clifton : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=a79e9a07a0d350031cd491031a756fbaa6a01df0 > > commit a79e9a07a0d350031cd491031a756fbaa6a01df0 > Author: Nick Clifton > Date: Mon Oct 16 15:48:26 2023 +0100 > > Fix: GNU-ld: ARM: Issues when trying to set target output architecture > > PR 28910 > * lexsup.c (ld_options): Require that the --architecture option is > given exactly two dashes, so that it does not become confused with the -a > option. I don't understand... In comment #6 you said this patch doesn't work, and now you apply it? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #17 from Stas Sergeev --- (In reply to Nick Clifton from comment #16) > Stas - if you can find a way to trigger the bug with these patches applied, > please feel free to reopen this PR. I tried to reproduce it again (w/o any patches), and just as you said in comment #14, I can't. So not sure what was the actual fix and what does your patch do, but let's hope its all good. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30974] DEFINED() always evaluates to 0
https://sourceware.org/bugzilla/show_bug.cgi?id=30974 --- Comment #1 from Stas Sergeev --- (In reply to Stas Sergeev from comment #0) > It would really help if you implement ASSERT() > natively, but this is another story. Except that ASSERT() is already there. :) I made sure that with ASSERT() the same bug can be tested, so not re-uploading the test-case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30974] DEFINED() always evaluates to 0
https://sourceware.org/bugzilla/show_bug.cgi?id=30974 --- Comment #3 from Stas Sergeev --- You need to consider being compatible with lld, which disagree with what you say. But that suggestion works for me, thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30984] New: assertion fail ../../bfd/elf.c:8485
https://sourceware.org/bugzilla/show_bug.cgi?id=30984 Bug ID: 30984 Summary: assertion fail ../../bfd/elf.c:8485 Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 15182 --> https://sourceware.org/bugzilla/attachment.cgi?id=15182&action=edit test case Please unpack the attached test-case and run "make". Results: ld: BFD (GNU Binutils for Ubuntu) 2.41 assertion fail ../../bfd/elf.c:8485 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30984] assertion fail ../../bfd/elf.c:8485
https://sourceware.org/bugzilla/show_bug.cgi?id=30984 --- Comment #1 from Stas Sergeev --- The test-case basically just creates the absolute section: .intel_syntax noprefix .section .text .code32 .global main ;.extern printf main: mov eax, 0xDEADBEEF push eax push message ; call printf add esp, 8 ret .section *ABS* message: .asciz "Register = %08X" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30984] assertion fail ../../bfd/elf.c:8485
https://sourceware.org/bugzilla/show_bug.cgi?id=30984 --- Comment #5 from Stas Sergeev --- Thank you. Could you please hint me how to create an absolute symbol? I already know that if I do symbol = ABSOLUTE(.); in a linker script, then there will be no dynamic relocs against this symbol. I wanted to experiment with this further, and create it from assembler. How can I do that? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 --- Comment #1 from Stas Sergeev --- It turned out R_RELC can be used instead of the custom reloc schemes. So that HPA work can be reduced to just this patch: diff --git a/gas/config/tc-i386.h b/gas/config/tc-i386.h index 80d66c1ce15..7b036a785b0 100644 --- a/gas/config/tc-i386.h +++ b/gas/config/tc-i386.h @@ -392,6 +392,9 @@ extern offsetT x86_sframe_cfa_ra_offset (void); extern unsigned char x86_sframe_get_abi_arch (void); #define sframe_get_abi_arch x86_sframe_get_abi_arch +/* Support computed relocations. */ +#define OBJ_COMPLEX_RELC + #endif #ifdef TE_PE Any reason why computed relocs are currently disabled in gas, and can that be changed? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30970] [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Stas Sergeev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Stas Sergeev --- I hacked up RELC support into nasm, and can confirm that these segelf relocs are completely redundant. There is nothing to upstream. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] New: strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 Bug ID: 31106 Summary: strip --strip-debug breaks relocations Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 15232 --> https://sourceware.org/bugzilla/attachment.cgi?id=15232&action=edit test case Attached is a test-case. It is an elf file fdppkrnl.35.10.elf with debug info. Please do: ``` $ readelf -r fdppkrnl.35.10.elf | grep ':s8:' | wc -l 65 $ strip --strip-debug fdppkrnl.35.10.elf $ readelf -r fdppkrnl.35.10.elf | grep ':s8:' | wc -l 1 ``` As we can see, strip removed relocations to a particular symbol (1 reloc left from 65). This renders the object disfunctional. llvm-strip works properly and doesn't break anything. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 Stas Sergeev changed: What|Removed |Added Attachment #15232|0 |1 is obsolete|| --- Comment #2 from Stas Sergeev --- Created attachment 15235 --> https://sourceware.org/bugzilla/attachment.cgi?id=15235&action=edit test case Re-attaching. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 --- Comment #3 from Stas Sergeev --- (In reply to Nick Clifton from comment #1) > Is it possible that you uploaded the stripped file ? Thank you. I have re-uploaded the file now (haven't checked if the first one was alredy stripped, but likely so) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 --- Comment #6 from Stas Sergeev --- (In reply to Nick Clifton from comment #4) > (Incidentally the symbols have very strange > looking names. Is this deliberate ?) This is a so-called "RELC encoding". I've looked into binutils source to find that it even exists. :) Now my modified nasm generates such symbols. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 --- Comment #8 from Stas Sergeev --- (In reply to Nick Clifton from comment #7) > Created attachment 15236 [details] > Proposed patch > > Hi Stas, > > Please can you try out this patch ? Hi, it would be easier if you just provide the newly stripped binary. I'll see if it works. But I can as well try the path. However: > So the patch tweaks the reloc processing code so that it will not > drop the symbol in complex relocs. Have you considered to spare the '--strip-debug' case from any possible heuristic, so that it only strips debug sections? I think your check should only apply to the normal strip process, but '--strip-debug' remains broken. It needs to keep any relocs, regardless of how safe is that. What do you think? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 --- Comment #11 from Stas Sergeev --- OK, I checked that the new binary works as expected. Thank you! But I am really a bit disappointed if you leave the current objcopy behavior that can still remove relocations at will... Yes, I understand that your patch fixes my problem. But IMHO having such side effects from mere objcopy, is plain wrong. > That would mean creating a separate path in the BFD If that's the problem, then I'd suggest no not touch relocations at all. It will fix both objcopy and '--strip-debug', and will actually regress nothing that I can think of? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/23854] New: -no-pie -export-dynamic corrupts binary
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 Bug ID: 23854 Summary: -no-pie -export-dynamic corrupts binary Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: critical Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 11375 --> https://sourceware.org/bugzilla/attachment.cgi?id=11375&action=edit test case Out of sudden my prog started to randomly crash on i386 target. It appears the combination of options -no-pie -export-dynamic causes ld to randomly corrupt the code section. Attached is the fully automated test-case. Just type "make" - it will link the executable and look with gdb at the assembler in one particular place where I spotted the corruption. It will then print "TEST FAILED!". You can run "make good" that will do the same but without -export-dynamic. This will end up in "TEST PASSED!". gold has no such problem. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23854] -no-pie -export-dynamic corrupts binary
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #2 from Stas Sergeev --- (In reply to H.J. Lu from comment #1) > dpmi.o has: > > 8f69: 8b 83 00 00 00 00 mov0x0(%ebx),%eax 8f6b: > R_386_GOT32X DPMI_return_from_realmode > 8f6f: 66 05 00 48 add$0x4800,%ax > 8f73: 66 2b 83 00 00 00 00sub0x0(%ebx),%ax8f76: > R_386_GOT32X DPMI_dummy_start > 8f7a: 66 89 46 30 mov%ax,0x30(%esi) These functions are not from dpmi.c, they are from another translation unit. The function of interest is "do_dpmi_int" - it gets corrupted, as my test-case shows. > Does dpmi.o contain normal i386 code? Yes, but not the ones you pointed to. These should be undefined in dpmi.c, and are actually written in 16bit asm. Please inspect "do_dpmi_int" instead - it is a valid C func from dpmi.o. You can see from my .gdbinit script where the corruption actually happens. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23854] -no-pie -export-dynamic corrupts binary
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #4 from Stas Sergeev --- (In reply to H.J. Lu from comment #3) > do_dpmi_int has Ah, I see now what you mean. > 8f69: 8b 83 00 00 00 00 mov0x0(%ebx),%eax 8f6b: > R_386_GOT32X DPMI_return_from_realmode > 8f6f: 66 05 00 48 add$0x4800,%ax > 8f73: 66 2b 83 00 00 00 00sub0x0(%ebx),%ax8f76: > R_386_GOT32X DPMI_dummy_start > 8f7a: 66 89 46 30 mov%ax,0x30(%esi) > 8f7e: 0f b7 45 2c movzwl 0x2c(%ebp),%eax > > Please show me the corresponding C code. Of course: https://github.com/stsp/dosemu2/blob/devel/src/dosext/dpmi/dpmi.c#L2053 The function is called "do_int31", but it gets inlined into do_dpmi_int. This is exactly the line you look for. The ugly macros are here: https://github.com/stsp/dosemu2/blob/devel/src/include/cpu.h#L138 https://github.com/stsp/dosemu2/blob/devel/src/include/bios.h#L161 I will also try to attach the dpmi.s with -verbose-asm for you tomorrow. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23854] -no-pie -export-dynamic corrupts binary
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #5 from Stas Sergeev --- Basically this code calculates the distance between "DPMI_return_from_realmode" and "DPMI_dummy_start", and puts the result into a 16bit variable. That explains the use of %ax. Its possible because those funcs are in 16bit asm. I think the gcc-generated asm code is perfectly fine here. It optimized the 32bit calculus to 16bits. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23854] -no-pie -export-dynamic corrupts binary
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #7 from Stas Sergeev --- Created attachment 11379 --> https://sourceware.org/bugzilla/attachment.cgi?id=11379&action=edit verbose asm > Please provide pre-processed dpmi.c from gcc -E and command-line > options to generate dpmi.s Unfortunately the problem only happens on a 32bit machine, I can't reproduce it with multilib on my 64bit one. So I'll provide what you ask for, later, when I get an access to the target machine. For now, here you have a verbose asm output. It seems the command line is also printed there, or at least its part. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23854] -no-pie -export-dynamic corrupts binary
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #8 from Stas Sergeev --- Created attachment 11381 --> https://sourceware.org/bugzilla/attachment.cgi?id=11381&action=edit preprocessed output -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23854] -no-pie -export-dynamic corrupts binary
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #9 from Stas Sergeev --- (In reply to H.J. Lu from comment #6) > Please provide pre-processed dpmi.c from gcc -E and command-line > options to generate dpmi.s gcc -xc -S -fverbose-asm -O -o dpmi.s dpmi.E gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04) Btw, could you please explain why the problem only happens with -export-dynamic? This doesn't seem to be related to the generated asm, AFAICT. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #12 from Stas Sergeev --- (In reply to H.J. Lu from comment #11) > Please add -fno-pie as workaround. Done. This works properly. Thank you. > > Btw, could you please explain why the problem > > only happens with -export-dynamic? This doesn't > > seem to be related to the generated asm, AFAICT. > It has nothing to do with -export-dynamic. My testcase doesn't use > -export-dynamic. But my does, and in fact, when you type "make good", the only things that changes, is no -export-dynamic. Could you please make sure I am not hitting the second bug here? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #14 from Stas Sergeev --- > H.J. Lu changed: > >What|Removed |Added > > Component|ld |gas Sorry for being pedantic, but there is no such problem with gold. So while gas may be involved too, I wonder are you sure there is no bug in ld itself. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #16 from Stas Sergeev --- > H.J. Lu changed: > Please try: > > https://sourceware.org/ml/binutils/2018-11/msg00021.html > > You need to compile with the new assembler. Building your git now... However. Are there really no hopes to link these already existing objects properly? gold have no problems with those, and if you consider them "broken" to the point that it isn't worth an efforts, then maybe at least ld can detect the problem and error out? Because its exactly ld that corrupted the instructions, and I really am surprised you didn't even put any small band-aid to stop it from ever doing so. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #19 from Stas Sergeev --- > H.J. Lu changed: > Your code doesn't conform to i386 psABI, which doesn't > support only using lower 16 bits of GOT entries. I would understand if linker writes me such an error. Silently producing corrupted binaries is the sign of low quality software. You can add checks, error messages, but never let the broken output... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #20 from Stas Sergeev --- I disasmed and diffed the object files without and with your patch. I see a lot of: --- 597,598c597,598 < 745: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi < 749: 8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi --- > 745: 8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi > 74c: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi --- Is this correct, that it now applies lea to %esi twice? As %esi is used as both arg and result, I think it will be modified twice, and so I can't imagine those changes lead to an equivalent code. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #23 from Stas Sergeev --- > What your code did is outside of scope of i386 psABI. Why not linker tells me so with an error msg? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #25 from Stas Sergeev ---
> What your code did is outside of scope of i386 psABI.
Why not linker tells me so with an error msg?(In reply to H.J. Lu from comment
#24)
> (In reply to Stas Sergeev from comment #23)
> > > What your code did is outside of scope of i386 psABI.
> >
> > Why not linker tells me so with an error msg?
>
> There are many corner cases linker doesn't check.
But in this particular case, when it overwrites the
instructions with something else, it _could_ have checked. :(
I don't think other unchecked corner cases give that
level of breakage and difficulty to debug.
> You have things like
>
> extern void foo (void);
>
> short
> foo_p (void)
> {
> return 0x400 - (int) &foo;
> }
>
> In normal i386 case, &foo is 32 bits, especially with PIE. BTW,
> does your code work without -no-pie using ANY linkers?
You mean, any other than ld, or including ld?
In fact, I added -no-pie just very recently:
https://github.com/stsp/dosemu2/commit/d5eb51320477f32df7deb9161fa728e12bcd06dd
to get the high load address.
Before that, it definitely worked with ld, and
most likely also with gold (but I haven't checked
gold for quite some time).
Note that older ubuntu distros (and likely others)
used no-pie by default. ubuntu defaulted to pie
only in 18.04 or so, which started to give me the
low load address again.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23854] 16-bit GOT access is incorrectly optimized
https://sourceware.org/bugzilla/show_bug.cgi?id=23854 --- Comment #26 from Stas Sergeev --- By the way, is it a feature of this bugzilla to open the entirely different bug ticket after I post any comment? This always makes me worry that I posted to wrong thread. For example, when I post to _this_ ticket, bugzilla opens ticket 14187. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/24033] New: internal error in address, at ../../gold/output.h:197
https://sourceware.org/bugzilla/show_bug.cgi?id=24033 Bug ID: 24033 Summary: internal error in address, at ../../gold/output.h:197 Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: stsp at users dot sourceforge.net CC: ian at airs dot com Target Milestone: --- Created attachment 11492 --> https://sourceware.org/bugzilla/attachment.cgi?id=11492&action=edit test case Please untar the test-case and run test.sh. gold will crash. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24035] New: wrong VMA when not specified explicitly
https://sourceware.org/bugzilla/show_bug.cgi?id=24035 Bug ID: 24035 Summary: wrong VMA when not specified explicitly Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 11493 --> https://sourceware.org/bugzilla/attachment.cgi?id=11493&action=edit test case Attached is a test-case. Please run test.sh. It will link multiple objects (of freedos) and look for a symbol address in the linker map. This symbol is in the section .ibss, which VMA is not specified in the linker script. The value that linker takes, looks completely wrong. It was reported that older linker (from ubuntu xenial) do work properly in this case, just using the VMA after the previous section, which is in this case .idata. But newer linker seems to use the VMA of the section .itext. I already fixed the linker script, but I think this behaviour change is a regression. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/25253] New: internal error in address, at output.h:197
https://sourceware.org/bugzilla/show_bug.cgi?id=25253 Bug ID: 25253 Summary: internal error in address, at output.h:197 Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: stsp at users dot sourceforge.net CC: ian at airs dot com Target Milestone: --- Created attachment 12108 --> https://sourceware.org/bugzilla/attachment.cgi?id=12108&action=edit test case Attached is a test-case, which is a rip-off of a real project. Test links only 1 file, other files are not included, and that should produce the undefined references normally. But is enough to trigger an error: ./test.sh ld.gold: internal error in address, at output.h:197 Same error happens when linking the entire project. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25254] New: internal error in set_address, at output.h:322
https://sourceware.org/bugzilla/show_bug.cgi?id=25254 Bug ID: 25254 Summary: internal error in set_address, at output.h:322 Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: stsp at users dot sourceforge.net CC: ian at airs dot com Target Milestone: --- Created attachment 12109 --> https://sourceware.org/bugzilla/attachment.cgi?id=12109&action=edit test case The attached test-case is causing this: $ ./test.sh ld.gold: error: a.o: file is empty ld.gold: internal error in set_address, at output.h:322 File is indeed empty, for the sake of the testing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27106] New: fistw not supported
https://sourceware.org/bugzilla/show_bug.cgi?id=27106
Bug ID: 27106
Summary: fistw not supported
Product: binutils
Version: 2.35.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
#include
int main()
{
int16_t w;
asm volatile("fist %0\n" : "=m"(w));
return 0;
}
fist.c: Assembler messages:
fist.c:6: Warning: no instruction mnemonic suffix given and no register
operands; using default for `fist'
And if you change to "fistw" then:
fist.c: Assembler messages:
fist.c:6: Error: invalid instruction suffix for `fist'
According to this:
https://www.felixcloutier.com/x86/fist:fistp
the 16bit variant should work.
"fistl" works fine.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/27106] fistw not supported
https://sourceware.org/bugzilla/show_bug.cgi?id=27106 --- Comment #2 from Stas Sergeev --- Yes, I tried "fists" already and noted it doesn't cause a warning or an error. But: s = single (32-bit floating point). So why would that be what I ask for? It doesn't look 16bit to me, or what am I missing? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27106] fistw not supported
https://sourceware.org/bugzilla/show_bug.cgi?id=27106 --- Comment #3 from Stas Sergeev --- The description is from here: https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax#Operation_Suffixes Hope its a valid one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27106] fistw not supported
https://sourceware.org/bugzilla/show_bug.cgi?id=27106 --- Comment #5 from Stas Sergeev --- OK, thank you. Would you like to fix the documentation? Am I right that it should say: s = single (16-bit integer or 32-bit floating point)? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32271] strip leaves unused PT_LOAD segments
https://sourceware.org/bugzilla/show_bug.cgi?id=32271 --- Comment #7 from Stas Sergeev --- (In reply to Nick Clifton from comment #6) > (In reply to Stas Sergeev from comment #5) > > > Even if it covers some "random" > > data in a file? IMHO that's still > > a but. If it would be zero-sized > > then fine. But its not. > > Can you provide a small example that reproduces this please ? It looks like > something that needs to be investigated. I think you just need to `strip --srip-debug -R '.note.*' tmp.elf` on an attached example. I can't claim anything, because I didn't check where the stalled segment points. But I assume it points to the invalid locations because its sections were removed? Or am I wrong? > My bad. The option is -Ttext-segment=... rather than --text-segment=... > Sorry. Wow! This actually works. So is it the same as just specifying the new load address for all segments? For example if I use -Trodata-segment then not all segments are moved, but -Ttext-segment seems to move them all, including notes. Could you please explain why it is so, or just assure me it will always move all segments? This seems to be all I need. > > Now it hints me to use -text-segment=0x08148000 > > only to declare it "unrecognized option"? > > Very funny. :) > > Yeah - the algorithm for hinting at spelling mistake corrections is not that > smart... Well, for sure it could at least check if such option actually exists, before suggesting. ld.lld (aka llvm ld) does the correct hint. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32271] strip leaves unused PT_LOAD segments
https://sourceware.org/bugzilla/show_bug.cgi?id=32271 --- Comment #5 from Stas Sergeev --- (In reply to Nick Clifton from comment #4) > Sure - if the segment is referencing beyond the of the file then it is a > bug. But if not then it is more of an unexpected behaviour than a real > fault. Even if it covers some "random" data in a file? IMHO that's still a but. If it would be zero-sized then fine. But its not. > You could always strip these note sections from the object files *before* > you link them together. Hmm, that's an interesting trick I guess. Its slightly more difficult to try out, but worth a try eventually. > Heresy! The glibc loader is perfect! Yeah, I know what you are talking about. :( Been there. > Have you tried linking with -Ttext=0x ? (And/or --text-segment=X > --rodata-segment=X --ldata-segment=X). Just trued, and wtf? $ x86_64-linux-gnu-ld int23.o int0.o asm.o ms.o plt.o -melf_i386 -static /usr/local/i386-pc-dj64/lib/uplt.o --text-segment=0x08148000 -o tmp.elf x86_64-linux-gnu-ld: unrecognized option '--text-segment=0x08148000' x86_64-linux-gnu-ld: use the --help option for usage information Wow, so lets try this then: $ x86_64-linux-gnu-ld int23.o int0.o asm.o ms.o plt.o -melf_i386 -static /usr/local/i386-pc-dj64/lib/uplt.o -text-segment=0x08148000 -o tmp.elf x86_64-linux-gnu-ld: Error: unable to disambiguate: -text-segment=0x08148000 (did you mean --text-segment=0x08148000 ?) Now it hints me to use -text-segment=0x08148000 only to declare it "unrecognized option"? Very funny. :) > Another possibility is to use your own linker script. Not only could this > script ensure that sections are loaded into the VA region you want, but you > could also have it discard all of those unwanted debug and note sections too. Another option that can actually work, but is yet more difficult to try. When I only need to change the default load address. :) Maybe fixing --text-segment or adding some opt to set default load address is a possibility? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32271] strip leaves unused PT_LOAD segments
https://sourceware.org/bugzilla/show_bug.cgi?id=32271 --- Comment #3 from Stas Sergeev --- Thanks for such a detailed reply! Its really helpful. (In reply to Nick Clifton from comment #2) > Agreed, although this is probably an enhancement rather than a bug. Having stalled PT_LOAD segment is most likely a bug. It probably refers to wrong offsets, or even past EOF? Or am I missing something that would make it still "somewhat" valid? > Have you tried using eu-strip (from the elfutils project) Tried just now: $ eu-strip --strip-debug -R '.note.*' tmp.elf eu-strip: Cannot remove allocated section '.note.gnu.property' So... it refuses to remove, leaving the file at least in a sane state. I believe binutils `strip` leaves a corrupted state. > or llvm-strip ? Same as binutils: unmapped PT_LOADs. > > Also I wonder why the segment that contains > > .note sections is PT_LOAD? Is this really > > needed? > > Because they are needed and used. At least by ld.so on Linux boxes. > The notes contain information about the architecture extensions needed > by the application that is being loaded and the loader makes sure that > these are available before starting to run the code. I guess its used by glibc, not an application? Or is there really an API to access that info from application? > > I have my own elf loader, and it > > gets confused by this all. > > It would probably be worth your while enhancing your loader so that it > can cope with these segments. Even if it just ignores them. It will > make things simpler in the long run. Here's the full problem. Those notes are added by build systems. For example debian build system adds .note.package. I am using --section-start switches for all "allocated" sections to move them to non-standard location, but if they are added behind my back, then they have the default location. When some sections are moved and some not, you end up with unloadable ELF because total VA space became too large. All loaders (even the one from glibc) estimate the total VA space by subtracting minimal address from maximal address, but in this case such estimation fails. So its not like I can deal with such ELFs, at least until I want my loader to be smarter than the one in glibc. :) The possible work-around can be if you tell me a magic option with which I can just change the default VA address, which seems to be 0x8048000 right now. Then I can drop those horrible --section-start tricks. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32271] New: strip leaves unused PT_LOAD segments
https://sourceware.org/bugzilla/show_bug.cgi?id=32271 Bug ID: 32271 Summary: strip leaves unused PT_LOAD segments Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 15745 --> https://sourceware.org/bugzilla/attachment.cgi?id=15745&action=edit test-case -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32271] strip leaves unused PT_LOAD segments
https://sourceware.org/bugzilla/show_bug.cgi?id=32271 --- Comment #1 from Stas Sergeev --- The attached test file is needed to reproduce the problem: $ readelf -l tmp.elf Section to Segment mapping: Segment Sections... 00 .note.gnu.property 01 .text 02 .bss 03 .note.gnu.property 04 .note.gnu.property 05 $ strip --strip-debug -R '.note.*' tmp.elf $ Section to Segment mapping: Segment Sections... 00 01 .text 02 .bss 03 04 05 (I have omitted some parts of readelf output for brevity). Now we see that the segment 0, which was previously covering .note sections, is unmapped, but still has non-zero size. Segments 3, 4 and 5 are also not removed, but they are not PT_LOAD, and have zero size, so do not harm. But segment 0 should be removed IMO. Also I wonder why the segment that contains .note sections is PT_LOAD? Is this really needed? I have my own elf loader, and it gets confused by this all. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32271] strip leaves unused PT_LOAD segments
https://sourceware.org/bugzilla/show_bug.cgi?id=32271 --- Comment #9 from Stas Sergeev --- (In reply to Nick Clifton from comment #8) > OK, so the -Ttext-segment sets the start address for the text segment > and by default the other segments (rodata & data) are mapped to start > after the end of the text segment. Yes, that's quite obvious. :) But: > Notes are considered to be read only data so they will normally be > put into the read only data segment, if one is being created, or the > text segment otherwise. And this is exactly not the case here, which is why I asked for the additional clarification: 00 .note.gnu.property 01 .text 02 .bss 03 .note.gnu.property 04 .note.gnu.property 05 rodata is segment 03 here. What makes me wonder is why -Ttext-segment relocates segment 00, which is before .text? Will this always be the case with the further versions of binutils? Also do you agree with my assumption that unmapped segment may refer to an invalid data? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32271] strip leaves unused PT_LOAD segments
https://sourceware.org/bugzilla/show_bug.cgi?id=32271 --- Comment #10 from Stas Sergeev --- Let me clarify. So with --Trodata-segment=0x08148000 I get this: ТипСмещ.Вирт.адр Физ.адрРзм.фйл Рзм.пм Флг Выравн LOAD 0x00 0x08048000 0x08048000 0x0011c 0x0011c R 0x1000 LOAD 0x001000 0x08049000 0x08049000 0x000c5 0x000c5 R E 0x1000 LOAD 0x00 0x08148000 0x08148000 0x0 0x00018 RW 0x1000 NOTE 0xf4 0x080480f4 0x080480f4 0x00028 0x00028 R 0x4 GNU_PROPERTY 0xf4 0x080480f4 0x080480f4 0x00028 0x00028 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x10 As you can see, only segment 03 have moved. So I assume 03 is rodata. >From here we see: 00 .note.gnu.property 01 .text 02 .bss 03 .note.gnu.property 04 .note.gnu.property 05 ... that .text is segment 01. This means 00 may not be moved with -Ttext-segment, but it actually is. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32464] New: ld allows adding 2 relative symbols. lld rejects
https://sourceware.org/bugzilla/show_bug.cgi?id=32464 Bug ID: 32464 Summary: ld allows adding 2 relative symbols. lld rejects Product: binutils Version: 2.43.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 15843 --> https://sourceware.org/bugzilla/attachment.cgi?id=15843&action=edit test-case Attached is a test-case. $ ./test.sh bfd linked allowed this, BAD ld.lld: error: kernel.ld:5: at least one side of the expression must be absolute lld linker rejected this, GOOD The culprit is this expression in linker script: SHOULD_FAIL = . + .; lld reject it with the above error message, while bfd linker silently allows. I believe it should be rejected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32463] New: linker script variables always go to ABS section
https://sourceware.org/bugzilla/show_bug.cgi?id=32463 Bug ID: 32463 Summary: linker script variables always go to ABS section Product: binutils Version: 2.43.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 15842 --> https://sourceware.org/bugzilla/attachment.cgi?id=15842&action=edit test-case Attached is the test-case that shows the problem. It links the same source with ld.bfd and ld.lld, and shows the difference: $ ./test.sh bfd: A _LGROUP lld: R _LGROUP As can be seen, bfd linker puts this symbol to ABS section, for the reasons completely unknown to me. I think lld does the right thing here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32461] ld: unrecognized option '--image-base=0x08148000'
https://sourceware.org/bugzilla/show_bug.cgi?id=32461 --- Comment #3 from Stas Sergeev --- OK, thanks. But what to do? Use different opts on ld and lld? lld says using -Ttext-segment is invalid, and I also suspected the same, because when I read segments with `readelf -l`, I see that Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x08148000 0x08148000 0x0011c 0x0011c R 0x1000 LOAD 0x001000 0x08149000 0x08149000 0x000c5 0x000c5 R E 0x1000 LOAD 0x00 0x0814a000 0x0814a000 0x0 0x00018 RW 0x1000 NOTE 0xf4 0x081480f4 0x081480f4 0x00028 0x00028 R 0x4 GNU_PROPERTY 0xf4 0x081480f4 0x081480f4 0x00028 0x00028 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x10 Section to Segment mapping: Segment Sections... 00 .note.gnu.property 01 .text 02 .bss 03 .note.gnu.property 04 .note.gnu.property 05 text segment is 1, so 0 will probably not move? What would be the portable way of setting the image base? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32461] ld: unrecognized option '--image-base=0x08148000'
https://sourceware.org/bugzilla/show_bug.cgi?id=32461 --- Comment #4 from Stas Sergeev --- Why not to stay compatible with lld here? It seems to be doing the right thing, at least in my understanding. So while its definitely up to you, I really suspect that closing this ticket is sub-optimal. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32460] New: section `.note.gnu.property' can't be allocated in segment 0
https://sourceware.org/bugzilla/show_bug.cgi?id=32460 Bug ID: 32460 Summary: section `.note.gnu.property' can't be allocated in segment 0 Product: binutils Version: 2.43.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 15841 --> https://sourceware.org/bugzilla/attachment.cgi?id=15841&action=edit test-case $ objcopy --only-keep-debug libtmp.so tmp.dbg objcopy: tmp.dbg: section `.note.gnu.property' can't be allocated in segment 0 LOAD: .init .plt .text .fini .note.gnu.property llvm-objcopy works normally. I think I haven't seen this message on an older binutils either. It seems to be not an error though, as tmp.dbg is created as the result. So I am not sure if this is a bug and where exactly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32461] New: ld: unrecognized option '--image-base=0x08148000'
https://sourceware.org/bugzilla/show_bug.cgi?id=32461 Bug ID: 32461 Summary: ld: unrecognized option '--image-base=0x08148000' Product: binutils Version: 2.43.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- $ ld --image-base=0x08148000 ld: unrecognized option '--image-base=0x08148000' Works (and produces the expected output when given object files) with ld.lld. man page documents this option. Note that ld.lld says that using -Ttext-segment instead of --image-base is invalid. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32460] section `.note.gnu.property' can't be allocated in segment 0
https://sourceware.org/bugzilla/show_bug.cgi?id=32460 --- Comment #2 from Stas Sergeev --- Created attachment 15849 --> https://sourceware.org/bugzilla/attachment.cgi?id=15849&action=edit new test case No custom linker here, no! Attached it a new test-case. Now it links libtmp.so from object files with plain `cc -shared -o libtmp.so` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32460] section `.note.gnu.property' can't be allocated in segment 0
https://sourceware.org/bugzilla/show_bug.cgi?id=32460 Stas Sergeev changed: What|Removed |Added Resolution|FIXED |MOVED --- Comment #10 from Stas Sergeev --- Sorry didn't mean to change status. It happened by itself! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32460] section `.note.gnu.property' can't be allocated in segment 0
https://sourceware.org/bugzilla/show_bug.cgi?id=32460 Stas Sergeev changed: What|Removed |Added Resolution|MOVED |FIXED --- Comment #9 from Stas Sergeev --- Done: https://bugzilla.redhat.com/show_bug.cgi?id=2332932 Thanks HjL! You are a man, no one else verifies that deeply. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32461] ld: unrecognized option '--image-base=0x08148000'
https://sourceware.org/bugzilla/show_bug.cgi?id=32461 --- Comment #6 from Stas Sergeev --- Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
