[Bug binutils/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)

2022-07-30 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #13 from Alan Modra --- I don't see anything unusual when I link comment #11 objects. Sure, the same file name is linked twice, but one is from subprojects/glib/gobject/libgobject-2.0.dll.a (defining g_value_init_from_instance) an

[Bug binutils/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)

2022-07-30 Thread luca.bacci at outlook dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #12 from Luca Bacci --- Clarification: some fields of flaginfo point to invalid memory. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)

2022-07-30 Thread luca.bacci at outlook dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #11 from Luca Bacci --- Ok, I can now reproduce the issue on Linux 1. Download the binutils-issue.zip archive: https://drive.google.com/file/d/17vAIVbxtBsubC0yjYiZClYejEwDTqJkA/view?usp=sharing 2. Extract the archive 3. Open a ter

[Bug binutils/29433] New: Detected memory leaks in readelf

2022-07-30 Thread tricker51449 at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29433 Bug ID: 29433 Summary: Detected memory leaks in readelf Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils

[Bug binutils/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)

2022-07-30 Thread luca.bacci at outlook dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #10 from Luca Bacci --- The code that repeatedly calls _bfd_coff_link_input_bfd() is in _bfd_coff_final_link(): https://github.com/bminor/binutils-gdb/blob/binutils-2_38/bfd/cofflink.c#L856 for (o = abfd->sections; o != NULL;

[Bug binutils/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)

2022-07-30 Thread luca.bacci at outlook dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #9 from Luca Bacci --- Created attachment 14245 --> https://sourceware.org/bugzilla/attachment.cgi?id=14245&action=edit Log of all the calls to _bfd_coff_link_input_bfd -- You are receiving this mail because: You are on the CC

[Bug binutils/29389] Failed assertions in bfd/cofflink.c and bfd/coff-x86_64.c during the linking stage (MSYS2 MinGW64)

2022-07-30 Thread luca.bacci at outlook dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #8 from Luca Bacci --- I have now more insights into what's going on... The issue stems from passing repeated import libs to the linker: ld.bfd -o out ... subprojects/glib/gobject/libgobject-2.0.dll.a ... "D:/msys64/mingw64/l

[Bug binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')

2022-07-30 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29348 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com

[Bug binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')

2022-07-30 Thread lienze at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=29348 --- Comment #9 from Enze Li --- Created attachment 14244 --> https://sourceware.org/bugzilla/attachment.cgi?id=14244&action=edit Preprocessed source for the failing compile $ cd /path/to/binutils-gdb $ ./configure --prefix=`pwd`/build CXXFL

[Bug binutils/29348] gdb/build: format specifies type 'unsigned long' but the argument has type 'bfd_size_type' (aka 'unsigned long long')

2022-07-30 Thread lienze at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=29348 --- Comment #8 from Enze Li --- (In reply to Alan Modra from comment #7) > That looks to be as expected. I wonder if your systems are typedef'ing > uint64_t as unsigned long long rather than unsigned long? To be honest, I didn't make any c