BTW, there are multiple existing tests that exercise the hack added for
this pr. One such is ld-elf/tbss1.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479
Title:
gzip
Should now be fixed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/2023437
Title:
ppc64el gold linker produces unusable clang-16 binary
Status in binutils:
Fix Releas
I've been going down the wrong rabbit hole, I should have asked you at
the outset to post the result of your g++ command with -v added. That
would have shown your compiler is defaulting to PIEs while mine is not.
Adding -pie to the gold command line shows a huge number of relative
dynamic relocati
Linking with your .so files still doesn't give me any difference between
gold-2.39 and gold mainline. I'm using my crt*.o, libc_nonshared.a,
libgcc.a. From ld -t output it seems nothing from libc_nonshared.a or
libgcc.a is extracted, so the only real difference ought to be crt1.o,
crti.o, crtn.o,
When I build clang-16 from your object files (plus my system libraries
and startup files) for powerpc64le using gold 2.40.50.20230614 I get
exactly the same binary as when using gold 2.39.0.20230101. That's
comparing gold from the tip of master and binutils-2_39-branch in
sourceware.org/git/binuti
Fixed mainline and 2.38 branch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1958389
Title:
Jammy builds of xen segfault, but only on launchpad x86 builders
Status in b
Created attachment 13937
Likely fix
>From the backtrace in https://bugs.debian.org/1004269 it is clear that
the problem is triggered by commit e86fc4a5bc37 in which a new extrap
field was added to coffcode.h combined_entry_type but is not used on
anything except rs6000 coff targets.
--
You recei
HJ, you likely can reproduce the failue with an asan build of binutils,
or using MALLOC_PERTURB_. I haven't tested the patch yet.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/
Documented
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/40214
Title:
ld checks for libs in wrong order. it should be inline with ld.so and
check configured folders fi
Closing
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479
Title:
gzip in Ubuntu Eoan results in Exec format error on WSL1
Status in binutils:
Fix Released
Status
Well, yes, but patches can be posted to binut...@sourceware.org without
a bugzilla open.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479
Title:
gzip in Ubuntu Eoan
(In reply to Balint Reczey from comment #2)
> Did I miss something?
You did. By subtracting off_adjust from the value written to p_offset
you potentially have p_offset mod page_size != p_vaddr mod page_size.
This will fail the glibc test in elf/dl-load.c resulting in "ELF load
command address/of
It looks to me like your fix ignores the following comment, and will
therefore cause problems with other loaders.
/* We shouldn't need to align the segment on disk since
the segment doesn't need file space, but the gABI
arguably requires the alignmen
Fixed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1845190
Title:
binutils nm wrong output format breaks i386 nm work
Status in binutils:
Fix Released
Status in bin
Fixed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1844119
Title:
readelf crash on 32bit, leading to abi-monitor testsuite regression
Status in binutils:
Fix Releas
Fixed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1833237
Title:
skiboot ftbfs in eoan
Status in binutils:
Fix Released
Status in binutils package in Ubuntu:
Con
This is due to a horrible linker script breaking a new GOT indirect to
GOT relative optimisation (git commit 066f4018ae78).
ld does a preliminary layout to see whether various optimisations can be
done. In this case the preliminary layout indicates that code using a
GOT indirect address can be re
It looks like the overlapping FDE error is caused by a bunch of zero
address range FDEs in
/usr/lib/llvm-3.5/lib/libclangCodeGen.a(CGStmtOpenMP.o). These do have
the potential to cause an exception handling problem at runtime, so ld
is correct to complain. (It might also be reasonable for ld to d
Build libOpenCL.so.1 with -Wl,-noinhibit-exec,-Map,libOpenCl.map and
look at the mapfile entries for .eh_frame. Try to match up with
addresses given for the overlapping FDE. This should give you the
object file(s) at fault. My guess is that further analysis will point
at an llvm bug.
--
You re
I don't believe trunk binutils is the source of the problem. Trunk
binutils (commit ae6c7e33 and aa8f4d1e) is merely letting you know about
a case where previous versions of ld silently created binaries with
potential runtime failures during exception handling.
--
You received this bug notificat
It looks like the overlapping FDE error is caused by a bunch of zero
address range FDEs in
/usr/lib/llvm-3.5/lib/libclangCodeGen.a(CGStmtOpenMP.o). These do have
the potential to cause an exception handling problem at runtime, so ld
is correct to complain. (It might also be reasonable for ld to d
I'm looking into moving the section headers to the end of the object
file for ld.bfd. It doesn't look too hard, but there will likely be
some testsuite tweaking needed. It looks like gold puts section headers
last.
--
You received this bug notification because you are a member of Ubuntu
Touch s
22 matches
Mail list logo
