[Bug gprofng/29593] error: '__u64' undeclared (first use in this function) for aarch64-linux-musl host
https://sourceware.org/bugzilla/show_bug.cgi?id=29593 Vladimir Mezentsev changed: What|Removed |Added Last reconfirmed||2023-01-11 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Vladimir Mezentsev --- I downloaded adelie-rootfs-mini-aarch64-1.0-rc2.txz : export https_proxy=https://www-proxy.us.oracle.com:80 export http_proxy=http://www-proxy.us.oracle.com:80 wget https://distfiles.adelielinux.org/adelie/1.0/iso/rc2/adelie-rootfs-mini-aarch64-1.0-rc2.txz sudo tar xf adelie-rootfs-mini-aarch64-1.0-rc2.txz But I can't download anything in the container: sudo systemd-nspawn -E https_proxy=https://www-proxy.us.oracle.com:80 -E http_proxy=http://www-proxy.us.oracle.com:80 --directory=. -M my_musl Spawning container my_musl on /tmp/adelie. Press ^] three times within 1s to kill container. -sh: 0: can't access tty; job control turned off my_musl # /sbin/apk add bash fetch https://distfiles.adelielinux.org/adelie/1.0/system/aarch64/APKINDEX.tar.gz ERROR: https://distfiles.adelielinux.org/adelie/1.0/system: network error (check Internet connection and firewall) fetch https://distfiles.adelielinux.org/adelie/1.0/user/aarch64/APKINDEX.tar.gz ERROR: https://distfiles.adelielinux.org/adelie/1.0/user: network error (check Internet connection and firewall) (1/1) Installing bash (4.4.23-r1) ERROR: bash-4.4.23-r1: network error (check Internet connection and firewall) 1 error; 38 MiB in 40 packages How can I resolve this problem ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #26 from H.J. Lu ---
(In reply to Rainer Orth from comment #25)
> Created attachment 14568 [details]
> Augmented patch
@@ -2853,9 +2866,18 @@ elf_i386_relocate_section (bfd *output_b
relend, h, r_symndx, true))
return false;
- if (r_type_tls == R_386_TLS_LE_32)
+ if (r_type_tls == R_386_TLS_LE_32
+ || (r_type_tls == R_386_TLS_LE
+ && htab->elf.target_os == is_solaris))
Please add and check "expected_tls_le".
{
- BFD_ASSERT (! unresolved_reloc);
+ /* NB: Solaris only supports R_386_TLS_GD->R_386_TLS_LE. */
+ BFD_ASSERT (! unresolved_reloc
+ && (htab->elf.target_os != is_solaris
+ || (htab->elf.target_os == is_solaris
+ && (r_type == R_386_TLS_GD
+ || r_type == R_386_TLS_IE
+ || r_type == R_386_TLS_GOTIE)
+ && r_type_tls == R_386_TLS_LE)));
No need to check R_386_TLS_LE here with "expected_tls_le".
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29981] Non-existing references to init.texi still present after bfd_init move
https://sourceware.org/bugzilla/show_bug.cgi?id=29981 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=18737d14799d609054994987dd75631430637a99 commit 18737d14799d609054994987dd75631430637a99 Author: Pekka Seppänen Date: Tue Jan 10 23:05:31 2023 +1030 PR 29981 references to init.texi -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29935] Callers of Java 'itable stubs' are wrong on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=29935 Kurt Goebel changed: What|Removed |Added Summary|Callers of Java 'itable |Callers of Java 'itable |stubs' are wrong on ARM64 |stubs' are wrong on ||aarch64 CC||kurt.goebel at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #25 from Rainer Orth --- Created attachment 14568 --> https://sourceware.org/bugzilla/attachment.cgi?id=14568=edit Augmented patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 Rainer Orth changed: What|Removed |Added Status|WAITING |NEW --- Comment #24 from Rainer Orth --- Sorry for dropping the ball on this one for so long. However, some time ago the issue broke the gcc trunk build with D included since d21 didn't run due to the unsupported reloc. I've now refreshed your patch and had to make two amendements: When linking GCC's gcc.dg/torture/tls/run-ie.c without and with -fPIC, the assertion would fire in two cases that seem legit: * r_type = R_386_TLS_IE, r_type_tls = R_386_TLS_LE * r_type = R_386_TLS_GOTIE, r_type_tls = R_386_TLS_LE If I let those two in, the gcc bootstrap finishes successfully and the testsuite run shows no regressions compared to a gas/ld build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29981] Non-existing references to init.texi still present after bfd_init move
https://sourceware.org/bugzilla/show_bug.cgi?id=29981 --- Comment #3 from Pekka Seppänen --- Thanks, your version is indeed much, much better than my hacky proposal :) Also, tried it, and it working as expected (which is not a surprise) for both native and cross-compiler targets. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29981] Non-existing references to init.texi still present after bfd_init move
https://sourceware.org/bugzilla/show_bug.cgi?id=29981 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- This was fixed with commit 56b3aa508cdb, except for .gitignore -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29983] 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite
https://sourceware.org/bugzilla/show_bug.cgi?id=29983 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com Status|NEW |ASSIGNED --- Comment #1 from Nick Alcock --- Fix under test. The root cause of this is a bug in the code which checks for outdated object file inputs from old compilers that emitted a func info section format that has never been supported by libctf: it mistakenly uses the wrong type for the value of the ctf_link_inputs hashtable and treats it as a much larger structure than it is: if unlucky and the controlling test fails, it tries to add stuff to a list of errors and warnings located far beyond the *actual* end of the structure in ctf_link_inputs. It rarely bites in practice because it is relatively unlikely to happen on systems with 64-bit pointers: we dereference the second pointer element of (what we think is a) ctf_dict and then dig out its fourth byte (the header flags word), but the corresponding element in the real structure is part of the ctfa_magic in a ctf_archive (always allocated in a normal ld link), and it just so happens that on a platform with 64-bit pointers the relevant bit of the magic appears to have the relevant flags turned off. But on 32-bit this can really bite, though it is very unlikely to cause anything but a crash and would require near-total control of the process and careful preparation of the heap to cause it to produce anything more than a crash. Nonetheless, will backport the fix to all applicable branches. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29983] New: 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite
https://sourceware.org/bugzilla/show_bug.cgi?id=29983 Bug ID: 29983 Summary: 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite Product: binutils Version: 2.36 Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: nick.alcock at oracle dot com Target Milestone: --- The observed failure looks like this when running the testsuite: failed with: , expected: FAIL: Diagnostics - No parent dictionary Originally reported by Matthias Klose: Indu Bhagat provided a nice traceback and much invaluable debugging without which tracking this down would have been a nightmare. Thank you both! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29981] New: Non-existing references to init.texi still present after bfd_init move
https://sourceware.org/bugzilla/show_bug.cgi?id=29981 Bug ID: 29981 Summary: Non-existing references to init.texi still present after bfd_init move Product: binutils Version: 2.41 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pexu at sourceware dot mail.kapsi.fi Target Milestone: --- Created attachment 14567 --> https://sourceware.org/bugzilla/attachment.cgi?id=14567=edit Remove remaining init.texi references Hi. There are still a couple of references to (then generated) init.texi present after bfd_init move [1]. - At bfd/doc/bfd.texi This causes build to fail with "bfd.texi:246: @include: could not find init.texi" - At .gitignore Attached a proposed patch that fixes these issues. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=b1c95bc4dd737d3d0a6c9a1b6e022e3ef85110bc -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25694] R_RISCV_TPREL_HI20 relocations cause riscv64 to add TEXTREL bit on executables
https://sourceware.org/bugzilla/show_bug.cgi?id=25694 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29980] New: error: undefined reference to plenty of exported symbols that are referenced as hidden symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29980 Bug ID: 29980 Summary: error: undefined reference to plenty of exported symbols that are referenced as hidden symbols Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: mh-sourceware at glandium dot org CC: ian at airs dot com Target Milestone: --- We've recently got this link failure with armv7 android Firefox, which appeared from some innocuous and unrelated change, and disappeared a few days later on some other unrelated change. Both BFD ld and gold fail, but lld doesn't. It might imply some kind of weird corner case. What's kind of special about the missing symbols is that they appear in a library that was produced by the rust compiler, and as such they are "normal" exported symbols, but they are referenced from C++ code compiled with clang, where they have a hidden visibility attached in the corresponding object files. That however is not a new setup, as that has been how Firefox is linked for years, and is still the case now that it works again. Here is a (large, unfortunately) tarball containing all the files needed to reproduce: https://drive.google.com/file/d/17HlPvI30nTTX2jdlnV0-erhn5dQZZKp2/view?usp=sharing The command to run is in the testcase/command file. -- You are receiving this mail because: You are on the CC list for the bug.
