[Bug binutils/29389] pe renaming implib breaks bfd/cache.c reopening of closed archives
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|amodra at gmail dot com|unassigned at sourceware dot org CC||nickc at sourceware dot org --- Comment #20 from Alan Modra --- Removing myself as assignee for this bug. I just don't know enough about the PE linker support to fix this. Clearly pe.em/pep.em can't write to the filename of an archive or object file (it can to an element of a non-thin archive!), so the code that is setting filename will need to set a new field in pe_tdata and that field used instead of the filename for mumble mumble mumble. Yes, I don't know more than what the comment tells me, that this is done for import tables. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29389] pe renaming implib breaks bfd/cache.c reopening of closed archives
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 Alan Modra changed: What|Removed |Added Summary|Failed assertions in|pe renaming implib breaks |bfd/cofflink.c and |bfd/cache.c reopening of |bfd/coff-x86_64.c during|closed archives |the linking stage (MSYS2| |MinGW64)| --- Comment #19 from Alan Modra --- This code in ld/emultempl/pe.em is the cause. (also in pep.em) /* Rename this implib to match the other one. */ if (!bfd_set_filename (is->the_bfd->my_archive, other_bfd_filename)) You just can't do that when the filename is needed to reopen closed files. -- 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)
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 Alan Modra changed: What|Removed |Added Last reconfirmed||2022-08-02 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #18 from Alan Modra --- (In reply to Luca Bacci from comment #16) > If I force the cache size on MSYS2 to a higher value, e.g. 500, then the > issue goes away. On the countrary, if I set the cache size to 10 on Linux, > then I can successfully reproduce the issue Ah ha! That's good detective work! Now that it also reproduces for me, I should be able to find out why the wrong file is being reopened. > would you accept a patch to increase the cache size on Windows? Yes, host specific code to find the resource limit would be nice. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 --- Comment #6 from H.J. Lu --- Created attachment 14248 --> https://sourceware.org/bugzilla/attachment.cgi?id=14248=edit A patch Try this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from H.J. Lu ---
[hjl@gnu-tgl-3 pr29435]$ cat foo.c
__attribute__ ((aligned(0x8000)))
void
foo (void)
{
}
[hjl@gnu-tgl-3 pr29435]$ gcc -c foo.c
[hjl@gnu-tgl-3 pr29435]$ ld -shared -o libfoo.so foo.o
[hjl@gnu-tgl-3 pr29435]$ readelf -Wl libfoo.so
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
LOAD 0x00 0x 0x 0x0002ad
0x0002ad R 0x1000
LOAD 0x008000 0x8000 0x8000 0x07
0x07 R E 0x8000
LOAD 0x009000 0x9000 0x9000 0x68
0x68 R 0x8000
LOAD 0x009f40 0xaf40 0xaf40 0xc0
0xc0 RW 0x8000
DYNAMIC0x009f40 0xaf40 0xaf40 0xc0
0xc0 RW 0x8
NOTE 0x009000 0x9000 0x9000 0x30
0x30 R 0x8
GNU_PROPERTY 0x009000 0x9000 0x9000 0x30
0x30 R 0x8
GNU_STACK 0x00 0x 0x 0x00
0x00 RW 0x10
GNU_RELRO 0x009f40 0xaf40 0xaf40 0xc0
0xc0 R 0x1
Section to Segment mapping:
Segment Sections...
00 .hash .gnu.hash .dynsym .dynstr
01 .text
02 .note.gnu.property .eh_frame
03 .dynamic
04 .dynamic
05 .note.gnu.property
06 .note.gnu.property
07
08 .dynamic
[hjl@gnu-tgl-3 pr29435]$
Only the second PLT_LOAD segment should have 0x8000 alignment.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 --- Comment #4 from Francois-Xavier Coudert --- We've had this issue across a bunch of different systems. Mine has Debian GLIBC 2.31-13+deb11u3 -- 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)
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #17 from Luca Bacci --- Beyond that, would you accept a patch to increase the cache size on Windows? It could help in improving performance -- 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)
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #16 from Luca Bacci --- On MSYS2, bfd/cache.c:bfd_cache_max_open() returns 10, while on Linux it returns 128 (because HAVE_GETRLIMIT is defined) If I force the cache size on MSYS2 to a higher value, e.g. 500, then the issue goes away. On the countrary, if I set the cache size to 10 on Linux, then I can successfully reproduce the issue (using the instructions in https://sourceware.org/bugzilla/show_bug.cgi?id=29389#c11) Hope it helps! Thanks, Luca -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Status|NEW |WAITING --- Comment #3 from H.J. Lu --- Please try binutils master branch. Which glibc are you using? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 --- Comment #2 from Francois-Xavier Coudert --- I have put a copy of the faulty library (built on x86_64 linux) as well as the same one (built without `DYNAMIC_ARCH`) at this URL if someone wants to debug this issue further: https://www.dropbox.com/s/yth3avnycvomv4d/binutils-debug.tar.gz?dl=0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435
--- Comment #1 from Francois-Xavier Coudert ---
How to reproduce:
1. Download and extract OpenBLAS-0.3.20 from
https://github.com/xianyi/OpenBLAS/archive/v0.3.20.tar.gz
2. Run:
$ DYNAMIC_ARCH=1 TARGET=CORE2 make libs netlib shared
3. Create a test.c file:
$ cat test.c
#include
#include
#include
#include "cblas.h"
int main(void) {
int i;
double A[6] = {1.0, 2.0, 1.0, -3.0, 4.0, -1.0};
double B[6] = {1.0, 2.0, 1.0, -3.0, 4.0, -1.0};
double C[9] = {.5, .5, .5, .5, .5, .5, .5, .5, .5};
cblas_dgemm(CblasColMajor, CblasNoTrans, CblasTrans,
3, 3, 2, 1, A, 3, B, 3, 2, C, 3);
for (i = 0; i < 9; i++)
printf("%lf ", C[i]);
printf("\\n");
if (fabs(C[0]-11) > 1.e-5) abort();
if (fabs(C[4]-21) > 1.e-5) abort();
return 0;
}
4. Compile and run:
$ gcc test.c -I ./build2 -L ./build2 -lopenblas -pthread && ./a.out
./a.out: error while loading shared libraries: libopenblas.so.0: cannot open
shared object file: No such file or directory
PS: If Openblas is built without DYNAMIC_ARCH=1, then the library produced
works.
--
You are receiving this mail because:
You are on the CC list for the bug.
Issue 49024 in oss-fuzz: binutils:fuzz_disas_ext-bfd_arch_i386: Abrt in i386_dis_printf
Updates: Labels: -restrict-view-commit Comment #3 on issue 49024 by sheriffbot: binutils:fuzz_disas_ext-bfd_arch_i386: Abrt in i386_dis_printf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49024#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 47177 in oss-fuzz: binutils:fuzz_readelf: Timeout in fuzz_readelf
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 47177 by sheriffbot: binutils:fuzz_readelf: Timeout in fuzz_readelf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47177#c3 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/29435] New: Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 Bug ID: 29435 Summary: Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned" Product: binutils Version: 2.38 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- This is an issue we originally saw during Homebrew CI on Linux: https://github.com/Homebrew/homebrew-core/pull/106978 We've narrowed it down to a binutils issues, and openblas maintainers seem to think the same: https://github.com/xianyi/OpenBLAS/issues/3708 Using the same setup, we see the build succeed and produce a working shared library with binutils 2.37, but produce an invalid library with binutils 2.38. We configure openblas with DYNAMIC_ARCH=1 USE_OPENMP=1 NUM_THREADS=56 TARGET=CORE2 Compiling and linking a small test program against the library build with binutils 2.38 gives: ./test: error while loading shared libraries: libopenblas.so.0: ELF load command address/offset not properly aligned The library is originally produced by this compilation command: gcc -O2 -DSMALL_MATRIX_OPT -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=56 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.20\" -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I.. -shared -o ../libopenblasp-r0.3.20.so \ -Wl,--whole-archive ../libopenblasp-r0.3.20.a -Wl,--no-whole-archive \ -Wl,-soname,libopenblas.so.0 -lm -lpthread -lgfortran -lm -lpthread -lgfortran -- 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)
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #15 from Luca Bacci --- Uh...how strange! One of the very first things that _bfd_coff_link_input_bfd() does is call obj_coff_external_syms() which seeks into the lib file and reads the external symbols table. When _bfd_coff_link_input_bfd() is run with input_bfd->filename == "libgobject_2_0_0_dll_d000431.o" for the second time, obj_coff_external_syms() is executed, which calls cache_bseek() (then _bfd_real_fseek(), then fseeko64()) with an offset of 73060, on both Linux and MSYS2. However, on Linux the read buffer is: (gdb) p abfd->where $19 = 73060 (gdb) p result $20 = 0 (gdb) n 405 in /usr/src/debug/binutils-2.38/bfd/bfdio.c (gdb) _bfd_coff_get_external_symbols (abfd=0x5bc67750) at /usr/src/debug/binutils-2.38/bfd/coffgen.c:1692 1692/usr/src/debug/binutils-2.38/bfd/coffgen.c: File o directory non esistente. (gdb) n 1694in /usr/src/debug/binutils-2.38/bfd/coffgen.c (gdb) n 1695in /usr/src/debug/binutils-2.38/bfd/coffgen.c (gdb) p syms $21 = (void *) 0x61e3c000 (gdb) x /150db syms 0x61e3c000: 46 116 101 120 116 0 0 0 0x61e3c008: 0 0 0 0 1 0 0 0 0x61e3c010: 3 0 46 105 100 97 116 97 0x61e3c018: 36 55 0 0 0 0 2 0 0x61e3c020: 0 0 3 0 46 105 100 97 0x61e3c028: 116 97 36 53 0 0 0 0 0x61e3c030: 3 0 0 0 3 0 46 105 0x61e3c038: 100 97 116 97 36 52 0 0 0x61e3c040: 0 0 4 0 0 0 3 0 0x61e3c048: 46 105 100 97 116 97 36 54 0x61e3c050: 0 0 0 0 5 0 0 0 0x61e3c058: 3 0 0 0 0 0 4 0 0x61e3c060: 0 0 0 0 0 0 1 0 0x61e3c068: 0 0 2 0 0 0 0 0 0x61e3c070: 36 0 0 0 0 0 0 0 0x61e3c078: 3 0 0 0 2 0 0 0 0x61e3c080: 0 0 74 0 0 0 0 0 0x61e3c088: 0 0 0 0 0 0 2 0 0x61e3c090: 0 0 0 0 0 0 (gdb) While on MSYS2 the read buffer is: _bfd_coff_get_external_symbols (abfd=0x1d47d7c2710) at ../../binutils-gdb/bfd/coffgen.c:1596 1596 if (bfd_seek (abfd, obj_sym_filepos (abfd), SEEK_SET) != 0) (gdb) 1598 syms = _bfd_malloc_and_read (abfd, size, size); (gdb) 1599 obj_coff_external_syms (abfd) = syms; (gdb) p size $9 = 144 (gdb) x /150db syms 0x1d40853a550: 48 1 0 0 0 0 0 0 0x1d40853a558: 1 0 0 0 0 0 48 -64 0x1d40853a560: 46 105 100 97 116 97 36 52 0x1d40853a568: 0 0 0 0 0 0 0 0 0x1d40853a570: 8 0 0 0 -16 0 0 0 0x1d40853a578: 58 1 0 0 0 0 0 0 0x1d40853a580: 1 0 0 0 0 0 48 -64 0x1d40853a588: 46 105 100 97 116 97 36 54 0x1d40853a590: 0 0 0 0 0 0 0 0 0x1d40853a598: 36 0 0 0 -8 0 0 0 0x1d40853a5a0: 0 0 0 0 0 0 0 0 0x1d40853a5a8: 0 0 0 0 0 0 48 -64 0x1d40853a5b0: -1 37 0 0 0 0 -112 -112 0x1d40853a5b8: 0 0 0 0 0 0 0 0 0x1d40853a5c0: 0 0 0 0 0 0 0 0 0x1d40853a5c8: 0 0 0 0 -88 1 103 95 0x1d40853a5d0: 118 97 108 117 101 95 114 101 0x1d40853a5d8: 103 105 115 116 101 114 95 116 0x1d40853a5e0: -85 -85 -85 -85 -85 -85 Using an hex editor we can see that on Linux the FILE* refers to d/msys64/mingw64/lib/libgobject-2.0.dll.a (which is right), on MSYS2 the FILE* refers to subprojects/glib/gobject/libgobject-2.0.dll.a (which is not right) -- 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)
https://sourceware.org/bugzilla/show_bug.cgi?id=29389 --- Comment #14 from Luca Bacci --- True! I'm going to investigate more... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29410] [display html] Argument " 0." isn't numeric in numeric gt (>)
https://sourceware.org/bugzilla/show_bug.cgi?id=29410 Kurt Goebel changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
