https://sourceware.org/bugzilla/show_bug.cgi?id=31924
Szabolcs Nagy changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #13 from Szabolcs Nagy ---
(In reply to Ard Biesheuvel from comment #12)
> RELR relocations fundamentally rely on the addend being present in the
> executable, as it is not stored anywhere else. This means
> --no-apply-dynamic-relo
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #9 from Szabolcs Nagy ---
it seems arm64 linux passes --no-apply-dynamic-relocs which means
the relative reloc addend is not stored to the referenced location
(0 is stored) and since -z pack-relative-relocs does not have the
addend
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #7 from Szabolcs Nagy ---
(In reply to H.J. Lu from comment #6)
> Does DT_RELR work in aarch64 glibc?
yes
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #4 from Szabolcs Nagy ---
i can confirm that boot fails depending on if vmlinux is linked with -z
pack-relative-relocs or not, so this is DT_RELR related.
i will try to debug this further.
--
You are receiving this mail because:
https://sourceware.org/bugzilla/show_bug.cgi?id=31847
Szabolcs Nagy changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://sourceware.org/bugzilla/show_bug.cgi?id=31850
Szabolcs Nagy changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
there should be no GOT entries allocated and no dynamic relocations in the
following binary:
$ cat bug.ld
OUTPUT_ARCH
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
relative relocation against an abs symbol is wrong, the GOT entry should be
initialized to the abs symbol value without dynamic relocation for it.
$ cat abs-got.s
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
$ cat bug.ld
OUTPUT_ARCH(aarch64)
SECTIONS
{
/DISCARD/ : { *(.discard) }
. = 0x1;
.text : { *(.text) }
. = 0x2
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
Szabolcs Nagy changed:
What|Removed |Added
Target Milestone|--- |2.42
--
You are receiving this mail
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #27 from Szabolcs Nagy ---
for the record a minimal reproducer when a bti veneer branches to itself:
$ cat a.s
.global _start
.type _start, %function
_start:
b foo
.zero 0x0700
$ cat b.s
.zero 0x0100
.g
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #26 from Szabolcs Nagy ---
(In reply to Szabolcs Nagy from comment #25)
> - *_bti_veneer is global symbol (not local)
sorry this is wrong, the sym binding is local as expected.
--
You are receiving this mail because:
You are on
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #25 from Szabolcs Nagy ---
for the record i built a mame binary where
$ readelf -aW mame |grep
_ZN3emu6detail16device_registrar15register_deviceERNS0_21device_type_impl_baseE
885688: 084323c812 FUNCLOCAL DEFAULT
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
bti veneer is only needed if the target instruction is not bti (or
paciasp,...), but bfd ld sometimes emits the veneer unnecessarily. (gnu
property is for BTI marking)
(introduced by the fix
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
Szabolcs Nagy changed:
What|Removed |Added
Last reconfirmed||2023-10-05
Status|UNCONFI
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #20 from Szabolcs Nagy ---
(In reply to Szabolcs Nagy from comment #18)
> i tried the specified steps and the bug is not reproducible.
(In reply to Nick Clifton from comment #19)
> (In reply to Szabolcs Nagy from comment #18)
> >
https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #18 from Szabolcs Nagy ---
i tried the specified steps and the bug is not reproducible.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30867
--- Comment #2 from Szabolcs Nagy ---
on a second thought gold likely requires
AX_CXX_COMPILE_STDCXX(11, , mandatory)
in its configure.ac
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30867
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=30076
Szabolcs Nagy changed:
What|Removed |Added
Target Milestone|--- |2.41
Resolution|---
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
ld may insert stubs with indirect branch if the call target is out of reach for
the direct call/branch instruction.
In BTI enaled code two stubs should be inserted with
https://sourceware.org/bugzilla/show_bug.cgi?id=22589
--- Comment #11 from Szabolcs Nagy ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Szabolcs Nagy from comment #9)
> > i ran into this again and i think the linker could relax 'adrp xN, weaksym'
> > into 'mov xN, 0' if weaksy
https://sourceware.org/bugzilla/show_bug.cgi?id=22589
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
e.g. on aarch64 assembling
foo .req x0
.unreq foo ;
fails with
:2: Error: unknown register alias 'foo;'
the ; should be a line sep
https://sourceware.org/bugzilla/show_bug.cgi?id=29310
--- Comment #8 from Szabolcs Nagy ---
still cannot reproduce it, the gcc i used for the build was
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/work/bgcc/install/libexec/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=29310
--- Comment #6 from Szabolcs Nagy ---
sorry i don't know what is "a profiled lto build"
i tried using debian g++-12 in a container with new binutils
doing a normal build with same config as seen in the build log.
(did not apply the debian gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=29310
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=26378
--- Comment #1 from Szabolcs Nagy ---
linux-kernel discussion:
https://lore.kernel.org/lkml/20200812160017.GA30302@linux-8ccs/
--
You are receiving this mail because:
You are on the CC list for the bug.
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
since binutils 2.35 i see WAX flags on some nobits sections:
$ cat a.s
.section.text.foo,"ax",@progbits
.global foo
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
Szabolcs Nagy changed:
What|Removed |Added
Target Milestone|--- |2.36
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=26339
--- Comment #1 from Szabolcs Nagy ---
i will have to check the rest but at least 'mte' is not an architecture
extension in the gnu tools, there is 'memtag' instead
i.e. -march=armv8.5-a+memtag is valid but -march=armv8.5-a+mte is not.
--
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
--- Comment #7 from Szabolcs Nagy ---
patch https://sourceware.org/pipermail/binutils/2020-July/112643.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
--- Comment #6 from Szabolcs Nagy ---
note on 32bit arm, sh and or1k .plt sh_entsize == 4 which
has nothing to do whith the plt entry size (which can
vary on arm). on sparc the logic is more complicated and
the plt entry size is used in some c
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=25903
--- Comment #1 from Szabolcs Nagy ---
bug 14675 may be related
--
You are receiving this mail because:
You are on the CC list for the bug.
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: nsz at gcc dot gnu.org
CC: ian at airs dot com
Target Milestone: ---
$ cat a.c
#include
#include
#include
#include
static _Unwind_Reason_Code unwind_backtrace_callback
https://sourceware.org/bugzilla/show_bug.cgi?id=25062
Szabolcs Nagy changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=25056
Szabolcs Nagy changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=25062
Szabolcs Nagy changed:
What|Removed |Added
Target Milestone|--- |2.34
--
You are receiving this mail
https://sourceware.org/bugzilla/show_bug.cgi?id=25056
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
Target
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
negative R_ARM_TLS_GOTDESC addend is not handled by ld
on 64-bit host, which can crash ld.
$ cat x.s
.text
.globl
https://sourceware.org/bugzilla/show_bug.cgi?id=24815
--- Comment #10 from Szabolcs Nagy ---
> /usr/bin/ld: /lib/liblzma.so.5: definition of lzma_end
...
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-pc-linux-musl/9.1.0/../../../../lib/libxml2.so:
> undefined reference to `lzma_end@XZ_5.0'
you need to ch
https://sourceware.org/bugzilla/show_bug.cgi?id=24815
Szabolcs Nagy changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment
ormal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
.global foo
foo:
ret
.symver foo, bar@V1
.symver foo, baz@V2
fails with
c.s: Assembler messages:
c.s:5: Error: multiple ver
45 matches
Mail list logo