[Bug binutils/28892] New: x86 OP_VEX use of uninitialised value
https://sourceware.org/bugzilla/show_bug.cgi?id=28892 Bug ID: 28892 Summary: x86 OP_VEX use of uninitialised value Product: binutils Version: 2.39 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: amodra at gmail dot com Target Milestone: --- Taken from a fuzzed object file. cat > xxx.s <
[Bug binutils/28893] New: binutils-2.37: PGO build with Clang results in configure error: AR with --plugin and rc is required for LTO build
https://sourceware.org/bugzilla/show_bug.cgi?id=28893
Bug ID: 28893
Summary: binutils-2.37: PGO build with Clang results in
configure error: AR with --plugin and rc is required
for LTO build
Product: binutils
Version: 2.37
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: telans at posteo dot de
Target Milestone: ---
Created attachment 13978
--> https://sourceware.org/bugzilla/attachment.cgi?id=13978&action=edit
build.log
Downstream Gentoo report: https://bugs.gentoo.org/833371
It appears that --enable-pgo-build requires checking for GCC plugin support
from within config/gcc-plugin.m4. This breaks the build when CC=clang with the
following:
configure: error: AR with --plugin and rc is required for LTO build
I believe this issue comes from binutils requesting a GCC LTO plugin regardless
of whether Clang is used or not:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=config/gcc-plugin.m4#l139
>From the above:
136 plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
137 plugin_option=
138 for plugin in $plugin_names; do
139 plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
140 if test x$plugin_so = x$plugin; then
141 plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
142 fi
143 if test x$plugin_so != x$plugin; then
144 plugin_option="--plugin $plugin_so"
145 break
146 fi
147 done
When GCC is used as $CC in the two commands, the outputs are:
telans@desktop ~ $ gcc --print-prog-name liblto_plugin.so
/usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.1/liblto_plugin.so
telans@desktop ~ $ gcc --print-file-name liblto_plugin.so
liblto_plugin.so
Compared to Clang:
telans@desktop ~ $ clang --print-prog-name liblto_plugin.so
liblto_plugin.so
telans@desktop ~ $ clang --print-file-name liblto_plugin.so
liblto_plugin.so
As on line 143, test is expecting a difference between the outputs which does
not occur using Clang (it might be testing for the existence of the plugin?).
I'm fairly sure these config tests can be skipped when using Clang + lld, but
I'm not sure. Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/28894] New: segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 Bug ID: 28894 Summary: segfault when building openjdk13 on x86 32bit (binutils 2.38 regression) Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jpalus at fastmail dot com Target Milestone: --- After switching to binutils 2.38 openjdk13 build failed on i686 with error: /usr/bin/ld: /tmp/B.zx6ygnoi/BUILD/jdk13u-jdk-13.0.10-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/objs/acce ss.o: warning: relocation in read-only section `.text._ZN14AccessInternal15RuntimeDispatchILy16464EP7oopDescLNS_11BarrierTypeE1 1EE11equals_initES2_S2_[_ZN14AccessInternal15RuntimeDispatchILy16464EP7oopDescLNS_11BarrierTypeE11EE11equals_initES2_S2_]' /usr/bin/ld: BFD (GNU Binutils) 2.38 assertion fail elfxx-x86.c:529 collect2: fatal error: ld terminated with signal 11 [Segmentation fault] compilation terminated. Just before upgrading binutils another build was successful with binutils 2.37. Note that x86_64 build succeeded with binutils 2.38. gcc 11.2.0 (with most of patches from gcc-11 patch) glibc 2.35 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28886] Configuration ns32k-unknown-netbsd is obsolete. Support has been REMOVED.
https://sourceware.org/bugzilla/show_bug.cgi?id=28886 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Martin Liska from comment #0) Hi Martin, > *** Configuration ns32k-unknown-netbsd is obsolete. > *** Support has been REMOVED. > The error is misleading as it's noted that it's obsolete > and the second line tells it's removed. Well these two lines have been in the sources for ages... Do you think that it would be better if they said: *** Configuration ns32k-unknown-netbsd is now obsolete *** and so support for it has been REMOVED. Or would you just prefer: *** Configuration ns32k-unknown-netbsd is no longer supported. Or maybe: *** Error: configuration ns32k-unknown-netbsd is no longer supported. Or even: *** Error: support for the obsolete configuration ns32k-unknown-netbsd has been REMOVED. Or something else ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Checking gold without libc.a
I have a CentOS system which does not have static glibc libraries installed (specifically, no libc.a). With binutils 2.38 and the --enable-gold option, make check fails because gold can't find libc.a. Is this expected behavior? Are the static glibc libraries required for gold's testing suite? Without --enable-gold, make check completes successfully. Thanks!
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-02-15 --- Comment #1 from H.J. Lu --- Please provide ALL linker inputs so that I can reproduce it on totally different machines. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28892] x86 OP_VEX use of uninitialised value
https://sourceware.org/bugzilla/show_bug.cgi?id=28892 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ce20459e162175710d8ef56118fc34edabfdce5e commit ce20459e162175710d8ef56118fc34edabfdce5e Author: H.J. Lu Date: Tue Feb 15 09:00:17 2022 -0800 x86: Add has_sib to struct instr_info Add has_sib to struct instr_info and use SIB info only if ins->has_sib is true. PR binutils/28892 * i386-dis.c (instr_info): Add has_sib. (get_sib): Set has_sib. (OP_E_memory): Replace havesib with ins->has_sib. (OP_VEX): Use ins->sib.index only if ins->has_sib is true. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28892] x86 OP_VEX use of uninitialised value
https://sourceware.org/bugzilla/show_bug.cgi?id=28892 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.39 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from H.J. Lu --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 Pierre Labastie changed: What|Removed |Added CC||pierre.labastie at neuf dot fr --- Comment #2 from Pierre Labastie --- Created attachment 13980 --> https://sourceware.org/bugzilla/attachment.cgi?id=13980&action=edit the version script -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28897] bdf/bdfio.c does not properly detect "long paths" containing ".."
https://sourceware.org/bugzilla/show_bug.cgi?id=28897 --- Comment #1 from Fred Eisele --- Created attachment 13982 --> https://sourceware.org/bugzilla/attachment.cgi?id=13982&action=edit The CMakeList.txt for building the sample. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28897] bdf/bdfio.c does not properly detect "long paths" containing ".."
https://sourceware.org/bugzilla/show_bug.cgi?id=28897 --- Comment #2 from Fred Eisele --- This affects several programs such as `ar.exe`, and `make.exe`. In those cases it only shows up when a relative path is provided and the combined length of that relative path and the path to the current working directory are greater than MAX_PATH. The following use of `ar.exe` on MSYS2 on Windows 10 illustrates the issue in practice. Setup a candidate directory structure. mkdir -p ./wip/sample/projects/Aaa/Bbb/Ccc/DdddEee/f/Ggg touch ./wip/sample/projects/Aaa/Bbb/Ccc/DdddEee/f/Ggg/_iii_iii___.o mkdir -p ./wip/HhhhHhhhH_1.1.1/KkkkK/Aaa/src/Bbb/DdddEee/Jjjj_Jjjj/foo/bar/baz/bow Then the following produces the error: pushd ./wip/HhhhHhhhH_1.1.1/KkkkK/Aaa/src/Bbb/DdddEee/Jjjj_Jjjj/foo/bar/baz/bow ls ../../../../../../../../../../.. ar cr foo.a ../../../../../../../../../../../sample/projects/Aaa/Bbb/Ccc/DdddEee/f/Ggg/_iii_iii___.o The error message is something like (when it happens): C:\tools\msys64\mingw64\bin\ar.exe: ../../../../../../../../../../../sample/projects/Aaa/Bbb/Ccc/DdddEee/f/Ggg/_iii_iii___.o: Invalid argument The problem can be cleared up by making doing a similar thing from a higher directory. e.g. pushd ./wip/HhhhHhhhH_1.1.1/KkkkK/Aaa/src/Bbb/DdddEee ls ../../../../../.. ar cr foo.a ../../../../../../sample/projects/Aaa/Bbb/Ccc/DdddEee/f/Ggg/_iii_iii___.o -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #4 from Pierre Labastie --- Problem is the compressed objs directory is ~240MB I cannot attach it. Don't know I can reduce it, sorry. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #5 from Pierre Labastie --- Created attachment 13983 --> https://sourceware.org/bugzilla/attachment.cgi?id=13983&action=edit the object file where the failure occurs -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #3 from Pierre Labastie --- I have a similar issue with openjdk-17.0.2 (in a 32 bit VM): /usr/bin/ld: /sources/openjdk/jdk17u-jdk-17.0.2-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/objs/adaptiveSizePolicy.o: warning: relocation in read-only section `.text' /usr/bin/ld: BFD (GNU Binutils) 2.38 assertion fail ../../bfd/elfxx-x86.c:529 collect2: fatal error: ld terminated with signal 11 [Segmentation fault] compilation terminated. The command line leading to that is: /usr/bin/g++ -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-O1 -Wl,--hash-style=gnu -march=i586 -m32 -shared -m32 -Wl,-version-script=/sources/openjdk/jdk17u-jdk-17.0.2-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/mapfile -Wl,-soname=libjvm.so -o /sources/openjdk/jdk17u-jdk-17.0.2-ga/build/linux-x86-server-release/support/modules_libs/java.base/server/libjvm.so @/sources/openjdk/jdk17u-jdk-17.0.2-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt -lm -ldl -lpthread -lrt I have attached the "version-script". The compressed directory objs (that contains all the object files unless I've missed something) will be attached next -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28897] New: bdf/bdfio.c does not properly detect "long paths" containing ".."
https://sourceware.org/bugzilla/show_bug.cgi?id=28897
Bug ID: 28897
Summary: bdf/bdfio.c does not properly detect "long paths"
containing ".."
Product: binutils
Version: 2.37
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: fredrick.eisele at gmail dot com
Target Milestone: ---
Created attachment 13981
--> https://sourceware.org/bugzilla/attachment.cgi?id=13981&action=edit
A sample illustrating the underlying issue.
This is a problem on Windows 10, it is related to PR 25713: "Handle extra long
path names. For relative paths, convert them to absolute, in case that version
is too long".
When the pathname is too long (MAX_PATH) the path modified by adding a prefix
'\\?\' to indicate that long path processing to be performed. This appears to
work as documented here:
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
and
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation
with one exception.
"Because it turns off automatic expansion of the path string, the "\\?\" prefix
also allows the use of ".." and "." in the path names, which can be useful if
you are attempting to perform operations on a file with these otherwise
reserved relative path specifiers as part of the fully qualified path."
The attached program source demonstrates that there is an issue with ".." in
the "long path" string.
Here is the offending code from bdf/bdfio.c.
[Lightly edited]
```
#elif defined (_WIN32)
size_t filelen;
/* PR 25713: Handle extra long path names.
For relative paths, convert them to absolute, in case that version is too
long. */
if (! IS_ABSOLUTE_PATH (filename) && (strstr (filename, ".o") != NULL))
{
char cwd[1024];
getcwd (cwd, sizeof (cwd));
filelen = strlen (cwd) + 1;
strncat (cwd, "\\", sizeof (cwd) - filelen);
++ filelen;
strncat (cwd, filename, sizeof (cwd) - filelen);
filename = cwd;
}
filelen = strlen (filename) + 1;
if (filelen > MAX_PATH - 1)
{
FILE * file;
char * fullpath;
inti;
fullpath = (char *) malloc (filelen + 8);
/* Add a Microsoft recommended prefix that
will allow the extra-long path to work. */
strcpy (fullpath, "?\\");
strcat (fullpath, filename);
/* Convert any UNIX style path separators into the DOS form. */
for (i = 0; fullpath[i]; i++)
{
if (IS_UNIX_DIR_SEPARATOR (fullpath[i]))
fullpath[i] = '\\';
}
fprintf(stderr, "k25: %s %s\n", modes, fullpath);
file = fopen (fullpath, modes);
fprintf(stderr, "k26: %d %s\n", errno, strerror(errno));
file = close_on_exec (file);
fprintf(stderr, "k27: %d %s\n", errno, strerror(errno));
free (fullpath);
return file;
}
```
The sample produces the following output.
```
C:\Users\fred\CLionProjects\bdfio-issue\cmake-build-debug\bdfio_issue.exe
k26: 18 w+b \\?\C:\tools\foo.o
k27: 0 No error
k26: 28 w+b \\?\C:\tools\msys64\..\foo.o
k27: 22 Invalid argument
Process finished with exit code 0
```
The sample presumes the existence of 'C:\tools\msys64\' and 'C:\tools\foo.o'.
As you can see the assumption that '..' can be included in the "long path" is
not correct. The error is misleading inasmuch as it implies that the problem is
with the 'mode' and not the path.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 Fred Eisele changed: What|Removed |Added CC||fredrick.eisele at gmail dot com --- Comment #22 from Fred Eisele --- PR 28897 This PR could be reopened or the fix could be done on the new PR. In any case, the problem Torbjörn SVENSSON mentioned is also true for '..' in the "long path". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #6 from Jan Palus --- Confirmed that issue also occurs on glibc 2.34. In my case command line is: /usr/bin/i686-pld-linux-g++ -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,relro -Wl,-z,noexecstack -Wl,-O1 -march=i586 -m32 -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc -static-libstdc++ -static-libgcc -shared -m32 -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc -Wl,-version-script=/home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u-jdk-13.0.10-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/mapfile -Wl,-soname=libjvm.so -o /home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u-jdk-13.0.10-ga/build/linux-x86-server-release/support/modules_libs/java.base/server/libjvm.so @/home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u-jdk-13.0.10-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt -lm -ldl -lpthread version script: http://jpalus.fastmail.com/version-script all object files: http://jpalus.fastmail.com/objs.tar.xz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #7 from H.J. Lu --- (In reply to Jan Palus from comment #6) > Confirmed that issue also occurs on glibc 2.34. > > In my case command line is: > > /usr/bin/i686-pld-linux-g++ -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,relro > -Wl,-z,noexecstack -Wl,-O1 -march=i586 -m32 -Wl,--as-needed > -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc > -static-libstdc++ -static-libgcc -shared -m32 -Wl,--as-needed > -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc > -Wl,-version-script=/home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u- > jdk-13.0.10-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/ > mapfile -Wl,-soname=libjvm.so -o > /home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u-jdk-13.0.10-ga/build/ > linux-x86-server-release/support/modules_libs/java.base/server/libjvm.so > @/home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u-jdk-13.0.10-ga/build/ > linux-x86-server-release/hotspot/variant-server/libjvm/objs/ > _BUILD_LIBJVM_objectfilenames.txt -lm -ldl -lpthread > > version script: http://jpalus.fastmail.com/version-script > all object files: http://jpalus.fastmail.com/objs.tar.xz Please provide @/home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u-jdk-13.0.10-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from H.J. Lu --- (In reply to H.J. Lu from comment #7) > > Please provide > @/home/users/atler/rpm/packages/BUILD.i686-linux/jdk13u-jdk-13.0.10-ga/build/ > linux-x86-server-release/hotspot/variant-server/libjvm/objs/ > _BUILD_LIBJVM_objectfilenames.txt No need for it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #9 from Pierre Labastie --- To be complete, my toolchain is: gcc-11.2.0, glibc-2.35, bintuils-2.38 I've installed binutils-2.37 and run the exact same command (that is, not recompiling the object files). Still, I see the warning: /usr/bin/ld: /sources/openjdk/jdk17u-jdk-17.0.2-ga/build/linux-x86-server-release/hotspot/variant-server/libjvm/objs/adaptiveSizePolicy.o: warning: relocation in read-only section `.text' But then I see: /usr/bin/ld: warning: creating DT_TEXTREL in a shared object and the link succeeds. Trying to bisect from 2.37 to 2.38 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 H.J. Lu changed: What|Removed |Added Assignee|unassigned at sourceware dot org |hjl.tools at gmail dot com Target Milestone|--- |2.39 Status|NEW |ASSIGNED --- Comment #10 from H.J. Lu --- It is caused by 3747999c6bd40a7ac905ef306a82214b336067b6 is the first bad commit commit 3747999c6bd40a7ac905ef306a82214b336067b6 Author: H.J. Lu Date: Mon Dec 27 10:13:06 2021 -0800 ld: Extract _bfd_elf_link_iterate_on_relocs -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #11 from H.J. Lu --- [hjl@gnu-tgl-3 pr28894]$ cat x.s .text addlfoo@INDNTPOFF, %eax .section .tbss,"awT",@nobits .globl foo .hidden foo foo: .byte 0 [hjl@gnu-tgl-3 pr28894]$ gcc -c -m32 x.s [hjl@gnu-tgl-3 pr28894]$ ld -shared -m elf_i386 x.o ld: BFD (Linux/GNU Binutils) 2.38.50.0.1.20220212 assertion fail /export/linux/src/binutils/binutils/bfd/elfxx-x86.c:547 Segmentation fault (core dumped) [hjl@gnu-tgl-3 pr28894]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3319ba7a8d6a42ba071d691789bc184632399331 commit 3319ba7a8d6a42ba071d691789bc184632399331 Author: H.J. Lu Date: Tue Feb 15 15:03:02 2022 -0800 i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTREL Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation in read-only section. bfd/ PR ld/28894 * elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow R_386_TLS_IE. ld/ PR ld/28894 * testsuite/ld-i386/i386.exp: Run pr28894. * testsuite/ld-i386/pr28894.d: New file. * testsuite/ld-i386/pr28894.s: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #13 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ae1cab7d3f39686d9c7ddadbac297e9ae76ffccf commit ae1cab7d3f39686d9c7ddadbac297e9ae76ffccf Author: H.J. Lu Date: Tue Feb 15 15:03:02 2022 -0800 i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTREL Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation in read-only section. bfd/ PR ld/28894 * elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow R_386_TLS_IE. ld/ PR ld/28894 * testsuite/ld-i386/i386.exp: Run pr28894. * testsuite/ld-i386/pr28894.d: New file. * testsuite/ld-i386/pr28894.s: Likewise. (cherry picked from commit 3319ba7a8d6a42ba071d691789bc184632399331) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from H.J. Lu --- Fixed for 2.39 and on 2.38 branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #15 from Jan Palus --- Confirmed openjdk builds fine with above fix. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
