[Bug binutils/30702] objcopy and strip invalidate the effect of ld option --no-insert-timestamp
https://sourceware.org/bugzilla/show_bug.cgi?id=30702 Jon Turney changed: What|Removed |Added CC||jon.turney at dronecode dot org.uk --- Comment #3 from Jon Turney --- I think for reproducible builds, we should really be doing whatever MS LINK's /Brepro flag does, which I believe is: * Add a IMAGE_DEBUG_TYPE_REPRO entry to the debug directory * Use a hash value for the "timestamp" I wrote some support for objdump to show these in [1], but skated out of the hard work of creating them. See https://sourceware.org/bugzilla/show_bug.cgi?id=16887 for why setting timestamps to zero should perhaps be approached with caution. [1] https://sourceware.org/pipermail/binutils/2020-January/109656.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26757] Cross and Native GDB Fails to Build on Cygwin
https://sourceware.org/bugzilla/show_bug.cgi?id=26757 Jon Turney changed: What|Removed |Added CC||jon.turney at dronecode dot org.uk --- Comment #3 from Jon Turney --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697 for some context. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/4933] windres does not escape path with spaces in them
https://sourceware.org/bugzilla/show_bug.cgi?id=4933 Jon Turney changed: What|Removed |Added CC||jon.turney at dronecode dot org.uk -- 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 binutils/18025] dwarf2 debug info after rebasing DLLs unusable
https://sourceware.org/bugzilla/show_bug.cgi?id=18025 --- Comment #16 from Jon Turney --- (In reply to Nick Clifton from comment #14) > The problem, I believe, is not the line number lookup code, but rather the > bias computation code. This is performing a linear scan of the symbol table > for every functional unit. Yes. > Please could you try out the uploaded patch. I found that with this applied > the "nm -l" scan of the cygstdc++6.dll took just 15 seconds, which I hope is > fast enough. Thanks very much for looking at this. This seems to work and is at least 10,000 times faster! Awesome :) -- 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 binutils/18025] dwarf2 debug info after rebasing DLLs unusable
https://sourceware.org/bugzilla/show_bug.cgi?id=18025 --- Comment #13 from Jon Turney --- (In reply to Nick Clifton from comment #11) > Have you tried using the latest binutils ? We did make some improvements to > line number caching recent. (Although I think that this was with DWARF not > STABS. Darn). Yes, I'm testing with binutils git master. > Is there a way to reproduce this problem in a Linux environment ? (I ask > because it is much easier for me to debug and fix problems in this > environment). > I did try uploading a copy of libstdc++.a from old cygwin installation > (based upon gcc 5.4.0) and then running "nm -l" on it with a newly built > x86_64-pc-cygin toolchain. It took 7 seconds to complete. So there must be > something that I am doing that does not match what you are doing. I would think that binutils built to handle pe-i386 targets would show the same behaviour on any host. I've attached a tar file containing an unstripped x86 cygstdc++.dll. For me, 'nm -l' on that is very slow, only managing to output a few symbols per second. Reverting 425bd9e1 makes it fast 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 binutils/18025] dwarf2 debug info after rebasing DLLs unusable
https://sourceware.org/bugzilla/show_bug.cgi?id=18025 --- Comment #12 from Jon Turney --- Created attachment 9949 --> https://sourceware.org/bugzilla/attachment.cgi?id=9949=edit example of a large object file demonstrating 'nm -l' slowdown -- 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 binutils/18025] dwarf2 debug info after rebasing DLLs unusable
https://sourceware.org/bugzilla/show_bug.cgi?id=18025 Jon Turney changed: What|Removed |Added CC||jon.turney at dronecode dot org.uk --- Comment #10 from Jon Turney --- (In reply to Corinna Vinschen from comment #9) > thanks a lot for the patch. I'll look into getting a new binutils for > the Cygwin distro soon. So, that update never happened, because 'nm -l' was reported to be very slow for large programs (e.g. an attempt at 'nm -l' for libstdc++ was abandoned after 48hrs), and I've just bisected that regression to this commit. Looking at the commit, even if the object isn't rebased, every symbol without linenumber information (e.g. type 'N' symbols) will cause an exhaustive, linear search for the symbol (I guess leading to polynomial runtime) I'm not sure how to improve this. I guess the bias for all symbols in a compilation unit is going to be the same, so there's some scope for caching that. -- 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 binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #14 from Jon Turney --- Created attachment 9666 --> https://sourceware.org/bugzilla/attachment.cgi?id=9666=edit Don't adjust size of PE/COFF merged .rsrc section Here's the alternate approach, of not allowing the .rsrc section to shrink. This seems to work ok (all the output .exe in my test case are valid), but this can waste a page in the output file (with the default manifest, potentially more if non-trivial resource sections were merged) -- 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 binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #13 from Jon Turney --- (In reply to Nick Clifton from comment #12) > > > > So, another fix is needed here. I'm trying to puzzle out where to move > > rsrc_process_section() to, but if you have any pointers, that would be most > > helpful. > > Hmm, tricky. The start of coffcode.h:coff_write_object_contents() would be > my > first choice, but I have no idea what sort pf problems you might encounter... _bfd_coff_final_link() seems to be the right place. I tried adding a hook which runs at the start of that before compute_section_file_positions() is called, but that's no good, I think because the contents of the output sections aren't actually determined at that point, so this seems a bit intractable without changing lots of stuff. -- 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 binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #11 from Jon Turney --- (In reply to Nick Clifton from comment #7) Lookng at this again, this is quite odd behaviour from the loader. Using my own PE dumper, which shows the VirtSize, on the testcase above: 1.exe (valid) Name VirtSize VMARawSizeOffset Flags .text 0758 1000 0800 0600 60500060 .data 0068 2000 0200 0e00 c0600040 .rdata 0370 3000 0400 1000 40500040 .buildid 0035 4000 0200 1400 40300040 .pdata 00d8 5000 0200 1600 40300040 .xdata 007c 6000 0200 1800 40300040 .bss 01c0 7000 c0600080 .idata 0268 8000 0400 1a00 c0300040 .rsrc 10e0 9000 0c00 1e00 c0300040 /4 .debug_aranges 0230 b000 0400 3000 42100040 /19 .debug_info 66a2 c000 6800 3400 42100040 /31 .debug_abbrev0afc 00013000 0c00 9c00 42100040 /45 .debug_line 0e37 00014000 1000 a800 42100040 /57 .debug_frame 02a0 00015000 0400 b800 42400040 /70 .debug_str 0102 00016000 0200 bc00 42100040 /81 .debug_loc 0745 00017000 0800 be00 42100040 /92 .debug_ranges0030 00018000 0200 c600 42100040 2.exe (valid) Name VirtSize VMARawSizeOffset Flags .text 0758 1000 0800 0400 60500060 .data 0068 2000 0200 0c00 c0600040 .rdata 0370 3000 0400 0e00 40500040 .buildid 0035 4000 0200 1200 40300040 .pdata 00d8 5000 0200 1400 40300040 .xdata 007c 6000 0200 1600 40300040 .bss 01c0 7000 c0600080 .idata 0268 8000 0400 1800 c0300040 .rsrc 10e0 9000 0c00 1c00 c0300040 3.exe (invalid) Name VirtSize VMARawSizeOffset Flags .text 0758 1000 0800 0400 60500060 .data 0068 2000 0200 0c00 c0600040 .rdata 0370 3000 0400 0e00 40500040 .buildid 0035 4000 0200 1200 40300040 .pdata 00d8 5000 0200 1400 40300040 .xdata 007c 6000 0200 1600 40300040 .bss 01c0 7000 c0600080 .idata 0268 8000 0400 1800 c0300040 .rsrc 10e0 9000 0c00 1c00 c0300040 /4 .gnu_debuglink 000c a000 0200 2800 42300040 The problem seems to manifest when the .rsrc section has a VirtSize greater than it's RawSize (which I believe should just mean that the loaded section is null padded) and the following section is the .gnu_debuglink, but not when there's no following section, or it's a .debug section. Playing around with the size of the .rsrc section, the problem first occurs when the VirtSize crosses the page alignement boundary (i.e. VirtSize = 0x1000) > Created attachment 9316 [details] > Proposed patch Anyhow, we can avoid this problem by giving the .rsrc section the right VirtSize, so this proposed patch seem the correct fix. (although I'm not quite sure if the virt_size should be set in pinfo->output_bfd rather than pinfo->abfd?) Unfortunately, as mentioned previously, this makes 1.exe invalid, but I think I can now see why that is: 1.exe (with patch, invalid) Name VirtSize VMARawSizeOffset Flags .text 0758 1000 0800 0600 60500060 .data 0068 2000 0200 0e00 c0600040 .rdata 0370 3000 0400 1000 40500040 .buildid 0035 4000 0200 1400 40300040 .pdata 00d8 5000 0200 1600 40300040 .xdata 007c 6000 0200 1800 40300040 .bss 01a0 7000 c0600080 .idata 0268 8000 0400 1a00 c0300040 .rsrc
[Bug binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #9 from Jon TURNEY --- Created attachment 9319 --> https://sourceware.org/bugzilla/attachment.cgi?id=9319=edit Output from test case with 2nd patch applied (In reply to Nick Clifton from comment #7) > Does this variation on your patch make a difference ? > > The change is to set the virtual size to the size *before* the .rsrc > section > is padded out to a file alignment boundary. This doesn't seem to help. Testing on x86_64, 1 is still invalid, 2 and 3 are valid. I'm not sure this is working as intended though, as the .rsrc section size is also the reported as the unpadded size. -- 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 binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #8 from Jon TURNEY --- (In reply to Nick Clifton from comment #6) > Question: in the 1.exe post-patch file the MinorLinkerVersion field in the > COFF > header shows 26, but in all the other .exe files, both pre- and post- patch, > the version number is reported as 25. Any idea why this might be ? This is the binutils version number. The current cygwin package is binutils 2.25.2 I only updated ld with a build from git master with the patch applied, 2.exe and 3.exe record the version number of objcopy used to make them? -- 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 binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #5 from Jon TURNEY --- Created attachment 9310 --> https://sourceware.org/bugzilla/attachment.cgi?id=9310=edit Output from test case with patch applied -- 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 binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #3 from Jon TURNEY --- Created attachment 9308 --> https://sourceware.org/bugzilla/attachment.cgi?id=9308=edit Output from test case (In reply to Nick Clifton from comment #2) > Hi Jon, > > Please could upload the 1.exe, 2.exe, 3.exe and 3.dbg files ? I do not > have a mingw64 build system here... No problem, attached. > It would be really nice if Windows could tell us *why* it does not like > 3.exe binary. Is there a Windows tool that dumps resources and which might > give a error message or two ? Yes, it's very annoying, but I have not found any tool to help verify the resources are loadable. -- 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 binutils/20193] New: Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 Bug ID: 20193 Summary: Invalid executable after adding debuglink to an executable produced after merging PE resource sections Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jon.turney at dronecode dot org.uk Target Milestone: --- Created attachment 9304 --> https://sourceware.org/bugzilla/attachment.cgi?id=9304=edit Test case It looks like merging of resource sections which are non-trivial occasionally produces executables which are invalid after further manipulation, e.g. after stripping and adding a debuglink section Attached testcase demonstrates this, on x86_64. 1.exe and 2.exe are valid, but Windows refuses to run 3.exe as an invalid executable. -- 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 binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #1 from Jon TURNEY --- I don't understand why only certain sizes of resource section seem to trigger this problem, but a couple of observations: I guess that the fact that the merged resource section can be smaller than the sum of the sizes, and thus can move under a page-size boundary has something to do with this bug. The size of the resources in the DataDirectory is not updated by rsrc_process_section() Since rsrc_process_section() takes place after bfd_coff_compute_section_file_positions(), allowing the .rsrc section to shrink seems problematic (I'm not sure how this interacts with the "page align the .rsrc section" patch in #16807) -- 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 binutils/18087] objcopy --compress-debug-sections can produce broken debug sections in PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=18087 Jon TURNEY changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jon TURNEY --- I believe this is resolved. -- 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/12969] ld silently generates bad DLL when there are more than 65536 exports
https://sourceware.org/bugzilla/show_bug.cgi?id=12969 Jon TURNEY changed: What|Removed |Added CC||jon.turney at dronecode dot org.uk -- 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 binutils/18087] objcopy --compress-debug-sections can produce broken debug sections in PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=18087 --- Comment #11 from Jon TURNEY jon.turney at dronecode dot org.uk --- (In reply to Nick Clifton from comment #9) Patch committed, with an addition of a fix to the gas testsuite for the x86 targets as pointed out by H.J. 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 binutils/18087] objcopy --compress-debug-sections can produce broken debug sections in PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=18087 --- Comment #6 from Jon TURNEY jon.turney at dronecode dot org.uk --- (In reply to Nick Clifton from comment #5) Thanks for taking a look. Your patch is good, but it misses a couple of points: * A change similar to the one in coffgen.c is needed in elf.c for ELF based targets. I thought I had done that. * The assembler needs to be updated as well so that it's --compress-debug-sections option only compresses when it is effective. * The documentation needs to be updated to explicitly mention that compression only happens when it is worthwhile. I have uploaded an extended version of your patch which should handle these points. Please could you try it out and let me know if it works for you. This seems to work fine. -- 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 binutils/18087] objcopy --compress-debug-sections can produce broken debug sections in PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=18087 Jon TURNEY jon.turney at dronecode dot org.uk changed: What|Removed |Added Attachment #8177|0 |1 is obsolete|| --- Comment #3 from Jon TURNEY jon.turney at dronecode dot org.uk --- Created attachment 8178 -- https://sourceware.org/bugzilla/attachment.cgi?id=8178action=edit Don't compress section if it doesn't get smaller -- 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 binutils/18087] New: objcopy --compress-debug-sections can produce broken debug sections in PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=18087 Bug ID: 18087 Summary: objcopy --compress-debug-sections can produce broken debug sections in PE binaries Product: binutils Version: 2.26 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jon.turney at dronecode dot org.uk Created attachment 8177 -- https://sourceware.org/bugzilla/attachment.cgi?id=8177action=edit Update section virtual size when it's compressed or decompressed PE binary support for objcopy --compress-debug-sections added in bug #14067 (commit a29a8af8) seems to have a problem when compression makes sections larger. Examining the unstripped XWin.exe for which the problem was reported [1] (using my own PE dumper as objdump -h transparently decompresses the compressed sections for you.) Section Name Virtual Size VMARawSize File Offset Characteristics .text 0017df74 1000 0017e000 0600 60500060 .data 4184 0017f000 4200 0017e600 c0700040 .rdata 000321e0 00184000 00032200 00182800 40700040 .buildid 0035 001b7000 0200 001b4a00 40300040 /4.eh_frame 00049240 001b8000 00049400 001b4c00 40300040 .bss eae0 00202000 c0700080 .edata 0002a0a5 00211000 0002a200 001fe000 40300040 .idata 4c70 0023c000 4e00 00228200 c0300040 .rsrc 7800 00241000 7400 0022d000 c0300040 .reloc d1bc 00249000 d200 00234800 42300040 /14 .debug_aranges 2fb0 00257000 3000 00241a00 42400040 /29 .debug_info 007c423e 0025a000 007c4400 00244a00 42100040 /41.debug_abbrev 00056487 00a1f000 00056600 00a08e00 42100040 /55 .debug_line 0009576a 00a76000 00095800 00a5f400 42100040 /67 .debug_frame 0038 00b0c000 0200 00af4c00 42300040 /80 .debug_str 00026a8b 00b0d000 00026c00 00af4e00 42100040 /91 .debug_loc 001799f0 00b34000 00179a00 00b1ba00 42100040 /102.debug_ranges 00038b88 00cae000 00038c00 00c95400 42100040 Compare with this after it's compressed using objcopy -compressed-debug-sections Section Name Virtual Size VMARawSize File Offset Characteristics .text 0017df74 1000 0017e000 0600 60500060 .data 4184 0017f000 4200 0017e600 c0700040 .rdata 000321e0 00184000 00032200 00182800 40700040 .buildid 0035 001b7000 0200 001b4a00 40300040 /4.eh_frame 00049240 001b8000 00049400 001b4c00 40300040 .bss eae0 00202000 c0700080 .edata 0002a0a5 00211000 0002a200 001fe000 40300040 .idata 4c70 0023c000 4e00 00228200 c0300040 .rsrc 7800 00241000 7400 0022d000 c0300040 .reloc d1bc 00249000 d200 00234400 42300040 /14 .zdebug_aranges 2fb0 00257000 1200 00241600 42400040 /30 .zdebug_info 007c423e 0025a000 00356200 00242800 42100040 /43 .zdebug_abbrev 00056487 00a1f000 d600 00598a00 42100040 /58 .zdebug_line 0009576a 00a76000 00040600 005a6000 42100040 /71.zdebug_frame 0038 00b0c000 0200 005e6600 42300040 /85 .zdebug_str 00026a8b 00b0d000 5c00 005e6800 42100040 /97 .zdebug_loc 001799f0 00b34000 0007de00 005ec400 42100040 /109 .zdebug_ranges 00038b88 00cae000 00013000 0066a200 42100040 It can be seen that the virtual size of the compressed sections is not updated, although the raw size has decreased. Normally this is not a problem, as nothing is accessing the section contents after the raw size. However, if the compressor has made the data bigger, it is truncated to the virtual size and decompression fails. Unfortunately, small .debug_frame sections seem to be quite normal on x86. Attached is a patch which updates the virtual size, which seems to fix this issue. Section Name Virtual Size VMARawSize File Offset Characteristics .text 0017df74 1000 0017e000 0600 60500060 .data 4184 0017f000 4200 0017e600 c0700040 .rdata 000321e0 00184000 00032200 00182800 40700040 .buildid 0035 001b7000 0200 001b4a00 40300040 /4.eh_frame 00049240
[Bug binutils/18087] objcopy --compress-debug-sections can produce broken debug sections in PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=18087 --- Comment #2 from Jon TURNEY jon.turney at dronecode dot org.uk --- (In reply to Kai Tietz from comment #1) Yes, it is likely that we have here an issue in updating section size, if compression actually increases, instead of decreasing size. IMO the saner approach would be to reject compression, if content gets larger as before I think my patch is no good because an output PE which is unstripped but has compressed debug sections is not valid, because it breaks the sections must have contiguous VMAs constraint. So not compressing if the section gets larger sounds like a better approach. I'll have a go at implementing that. -- 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
