[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows
https://sourceware.org/bugzilla/show_bug.cgi?id=29973 --- Comment #27 from cqwrteur --- Created attachment 14659 --> https://sourceware.org/bugzilla/attachment.cgi?id=14659&action=edit iostream -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows
https://sourceware.org/bugzilla/show_bug.cgi?id=29973 --- Comment #26 from cqwrteur --- (In reply to cqwrteur from comment #25) > (In reply to Nick Clifton from comment #24) > > Created attachment 14656 [details] > > Proposed patch > > > > Hi, > > > > Oops - I forgot about section names containing the $ character. > > > > Please could you try out this revised patch and let me know if it works > > properly this time. > > > > Cheers > > Nick > > looks like it is working now. However, I will try to build CMake to try > whether it works out. cqwrteur@HOME-SERVER:~/Temp$ wine ./iostream.exe wine: Unhandled page fault on read access to 0004FEAABEB0 at address 0003BE9ED6CD (thread 00ec), starting debugger... Unhandled exception: page fault on read access to 0x4feaabeb0 in 64-bit code (0x000 3be9ed6cd). Register dump: No it is still not working for iostream -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows
https://sourceware.org/bugzilla/show_bug.cgi?id=29973 --- Comment #25 from cqwrteur --- (In reply to Nick Clifton from comment #24) > Created attachment 14656 [details] > Proposed patch > > Hi, > > Oops - I forgot about section names containing the $ character. > > Please could you try out this revised patch and let me know if it works > properly this time. > > Cheers > Nick looks like it is working now. However, I will try to build CMake to try whether it works out. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c
https://sourceware.org/bugzilla/show_bug.cgi?id=30079 --- Comment #5 from Christoph Reiter --- (In reply to Michael Matz from comment #3) > If you can tar up the object files I can take a look myself (I don't have > cross compilers here, but cross binutils). See above, if you want :) > Or you add the guard > back again and see how that goes. I did that in https://github.com/msys2/MINGW-packages/pull/15540 now which fixed it for this example. Once it's in the repo I can ask the affected users to try again. thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30082] ld-bootstrap/bootstrap.exp should use LDFLAGS not CFLAGS
https://sourceware.org/bugzilla/show_bug.cgi?id=30082 Romain Geissler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Romain Geissler --- Hi, My initial issue is fixed (as it was only about not being able to find the zstd lib installed in a non standard location). Despite not passing LDFLAGS to this tests, at least we pass the right library flags, so I would say that is enough for now and we can close this ticket. Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c
https://sourceware.org/bugzilla/show_bug.cgi?id=30079 --- Comment #4 from Christoph Reiter --- Created attachment 14658 --> https://sourceware.org/bugzilla/attachment.cgi?id=14658&action=edit object file + lib -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c
https://sourceware.org/bugzilla/show_bug.cgi?id=30079
--- Comment #3 from Michael Matz ---
The guards are supposed to be moved only, not removed:
if (!wild->filenames_sorted
&& (sec == NULL || sec->spec.sorted == none
|| sec->spec.sorted == by_none))
{
return wild->rightmost;
}
...
while (*tree) {
if (wild->filenames_sorted) {
...
if (i > 0) ... continue; else if (i < 0) ... continue;
if (fa || la) {
...
if (i > 0) ... continue else if (i < 0) ... continue;
}
}
...
compare_section (sec->spec.sorted, section, (*tree)->section) < 0)
...
So it could only get to calling compare_section() (with sec->spec.sorted being
none or by_none) when ->filename_sorted _and_ it falls through the compare
based on these names (i.e. if filenames are equal and containing archives (if
they exist) are equal).
I probably convinced myself that this situation is not supposed to happen,
and as testcases were totally missing I didn't notice otherwise.
If you can tar up the object files I can take a look myself (I don't have
cross compilers here, but cross binutils). Or you add the guard
back again and see how that goes.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c
https://sourceware.org/bugzilla/show_bug.cgi?id=30079 --- Comment #2 from Christoph Reiter --- It looks like the guards before calling compare_section() were dropped in the new sorting code compared to the old one: https://github.com/bminor/binutils-gdb/commit/af31506c31a59a6edbb13498d6075fa704b801cd#diff-a914d0473272b436f9df11b7baced0716e595c73daca00d118a733bf3d915b02L2866-L2870 For extra context, here is a downstream bug report: https://github.com/msys2/MINGW-packages/issues/15469 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30093] gprofng SIGSEGV when processing unusual dwarf
https://sourceware.org/bugzilla/show_bug.cgi?id=30093 Kurt Goebel changed: What|Removed |Added Last reconfirmed||2023-02-07 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||kurt.goebel at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30080] nm docs mention read-only twice
https://sourceware.org/bugzilla/show_bug.cgi?id=30080 --- Comment #6 from Nick Clifton --- (In reply to Andreas Schwab from comment #5) > See commit a3b6428fe79. .comment and .note eh ? I wonder why they would have symbols ? Still fair enough, such symbols can obviously be produced. I stand by the updated description of the 'n' symbol though. Thanks for pointing out that commit Andreas. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30080] nm docs mention read-only twice
https://sourceware.org/bugzilla/show_bug.cgi?id=30080 --- Comment #5 from Andreas Schwab --- See commit a3b6428fe79. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c
https://sourceware.org/bugzilla/show_bug.cgi?id=30079 Christoph Reiter changed: What|Removed |Added CC||matz at suse dot de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30080] nm docs mention read-only twice
https://sourceware.org/bugzilla/show_bug.cgi?id=30080 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Hi Tom, Yeah - I suspect some PE/COFF special symbol type, but I could not find any way actually trigger nm to output that type... Anyway I have checked in the suggested change, although I extended it to note that 'n' symbols are also not debugging symbols. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c
https://sourceware.org/bugzilla/show_bug.cgi?id=30079 Christoph Reiter changed: What|Removed |Added CC||reiter.christoph at gmail dot com --- Comment #1 from Christoph Reiter --- Using the reproducer bisected to: I can also confirm that reverting it on top of 2.40 makes things work again (assuming I resolved the conflicts correctly) . --- af31506c31a59a6edbb13498d6075fa704b801cd is the first bad commit commit af31506c31a59a6edbb13498d6075fa704b801cd Author: Michael Matz Date: Thu Nov 10 16:06:20 2022 +0100 Only use wild_sort_fast there's no reason why the tree-based variant can't always be used when sorting is required, it merely needs to also support filename sorting and have a fast path for insertion at end (aka rightmost tree leaf). The filename sorting isn't tested anywhere and the only scripttempl that uses it is avr (for 'SORT(*)(.ctors)'), and I believe even there it was a mistake. Either way, this adds a testcase for filename sorting as well. Then the non-BST based sorting can be simplified to only support the fast case of no sorting required at all (at the same time renaming the two variants to _sort and _nosort). ld/ldlang.c | 302 +++ ld/ldlang.h | 3 +- ld/testsuite/ld-scripts/sort-file.d | 18 +++ ld/testsuite/ld-scripts/sort-file.t | 6 + ld/testsuite/ld-scripts/sort-file1.s | 6 + ld/testsuite/ld-scripts/sort-file2.s | 6 + 6 files changed, 163 insertions(+), 178 deletions(-) create mode 100644 ld/testsuite/ld-scripts/sort-file.d create mode 100644 ld/testsuite/ld-scripts/sort-file.t create mode 100644 ld/testsuite/ld-scripts/sort-file1.s create mode 100644 ld/testsuite/ld-scripts/sort-file2.s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30080] nm docs mention read-only twice
https://sourceware.org/bugzilla/show_bug.cgi?id=30080 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3a8be578d658b1cad3579aea0f5ce4883de21e6b commit 3a8be578d658b1cad3579aea0f5ce4883de21e6b Author: Nick Clifton Date: Tue Feb 7 11:40:46 2023 + Fix documentation of the 'n' symbol type displayed by nm. PR 30080 * doc/binutils.texi (nm): Update description of the 'n' symbol type. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows
https://sourceware.org/bugzilla/show_bug.cgi?id=29973 Nick Clifton changed: What|Removed |Added Attachment #14652|0 |1 is obsolete|| --- Comment #24 from Nick Clifton --- Created attachment 14656 --> https://sourceware.org/bugzilla/attachment.cgi?id=14656&action=edit Proposed patch Hi, Oops - I forgot about section names containing the $ character. Please could you try out this revised patch and let me know if it works properly this time. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30092] Build failed due to directory gas/doc was not created
https://sourceware.org/bugzilla/show_bug.cgi?id=30092 --- Comment #7 from Alan Modra --- Huh, thanks for sorting out the problem. Unfortunately the next commit doesn't just delete .dirstamp but also bumps the version and sets development=true. So we can't make the problem disappear by moving the tag, We'd need to rewrite history on the branch, which isn't allowed for anyone including me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30092] Build failed due to directory gas/doc was not created
https://sourceware.org/bugzilla/show_bug.cgi?id=30092 Robin Lee changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Robin Lee --- I found out 'gas/doc/.dirstamp' actually exists in the tree of tag 'binutils-2_40'. https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/doc/.dirstamp;h=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391;hb=32778522c7d8777803c88684b8e428ee729f0b22 And it was deleted in the next commit right after tag 'binutils-2_40'. So people building with source from tag 'binutils-2_40' may face this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30093] New: gprofng SIGSEGV when processing unusual dwarf
https://sourceware.org/bugzilla/show_bug.cgi?id=30093 Bug ID: 30093 Summary: gprofng SIGSEGV when processing unusual dwarf Product: binutils Version: 2.41 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: gilles.m.duboscq at gmail dot com Target Milestone: --- When running gprofng display text on some executables that contain unusual dwarf data I am getting a segfault. In particular, the input dwarf has some compilation units (DW_TAG_compile_unit) that have neither DW_AT_comp_dir nor DW_AT_stmt_list. The issue is that when that happens, DwrCU::stmt_list_offset remains 0, as a result, in Dwarf::archive_Dwarf, the `get_dwrLineReg` call will process whatever is at offset 0 in .debug_line. Then while looking for source files, `DwrLineRegs::getPath` will potentially try to use include_directories->fetch (0) which is NULL (no comp_dir attribute). This leads to a segfault in StringBuilder::append. For reference, discussion on the dwarf-producing side: https://github.com/oracle/graal/issues/5907 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30092] Build failed due to directory gas/doc was not created
https://sourceware.org/bugzilla/show_bug.cgi?id=30092 --- Comment #5 from Andreas Schwab --- Please make sure you have a pristine source directory if you are building outside of it. -- You are receiving this mail because: You are on the CC list for the bug.
