[Bug binutils/32926] binutils-gdb ld test with clang toolchain creates infinte looping readelf run
https://sourceware.org/bugzilla/show_bug.cgi?id=32926 H.J. Lu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 32809 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32809] readelf doesn't dump .debug_loclists section correctly for 64-bit target and mixed dwarf4/5 content
https://sourceware.org/bugzilla/show_bug.cgi?id=32809 H.J. Lu changed: What|Removed |Added CC||fche at redhat dot com --- Comment #6 from H.J. Lu --- *** Bug 32926 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32927] New: readelf --dwarf-check --debug-dump=Ranges produces nonsense warnings for DWARF 4 and DWARF5
https://sourceware.org/bugzilla/show_bug.cgi?id=32927 Bug ID: 32927 Summary: readelf --dwarf-check --debug-dump=Ranges produces nonsense warnings for DWARF 4 and DWARF5 Product: binutils Version: 2.45 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hmeyer.eu at gmail dot com Target Milestone: --- example output from --dwarf-check --debug-dump=Ranges: DWARF4/debug_ranges: Offset BeginEnd 36d4 36d4 (start == end) 36d8 36dc readelf: Warning: There is a hole [0 - 0x30] in .debug_ranges section. 0030 36d4 36d8 0030 36dc 36e5 0030 readelf: Warning: There is a hole [0x30 - 0x60] in .debug_ranges section. 0060 3704 3704 (start == end) 0060 3708 370c 0060 readelf: Warning: There is a hole [0x60 - 0x90] in .debug_ranges section. 0090 3704 3708 0090 370c 3715 0090 DWARF5/debug_rnglists: Offset BeginEnd 000c 36d4 (base address) 0015 36d4 36d4 (start == end) 0018 36d8 36dc 001b readelf: Warning: There is a hole [0xc - 0x1c] in .debug_rnglists section. 001c 36d4 (base address) 0025 36d4 36d8 0028 36dc 36e5 002b readelf: Warning: There is a hole [0x1c - 0x2c] in .debug_rnglists section. 002c 3704 (base address) 0035 3704 3704 (start == end) 0038 3708 370c 003b The hole check always triggers, even if the other output shows that there are no holes. If the hole check triggers, it prevents the overlap check from triggering, even if there are overlaps. However, it is normal for compilers (GCC 13 and later) to produce overlapping rangelists in debug_rnglists as noted in the discussion of bug 30792. readelf --dwarf-check --debug-dump=Ranges seems to be broken for all versions since 2.35, which is the oldest I tested (debian oldstable). I have not attached a binary, it seems to be wrong for all inputs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32927] readelf --dwarf-check --debug-dump=Ranges produces nonsense warnings for DWARF 4 and DWARF5
https://sourceware.org/bugzilla/show_bug.cgi?id=32927 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2025-04-29 --- Comment #1 from H.J. Lu --- Need a testcase in C or assembly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #18 from H.J. Lu --- This is the current patch: https://sourceware.org/pipermail/binutils/2025-April/140767.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32927] readelf --dwarf-check --debug-dump=Ranges produces nonsense warnings for DWARF 4 and DWARF5
https://sourceware.org/bugzilla/show_bug.cgi?id=32927
--- Comment #2 from Henning Meyer ---
The following C++ program represents the simplest example I could find that is
complicated enough to warrant the creation of discontinuous ranges in debug
information:
#include
struct Base {};
void func() {
static std::unique_ptr varStatic = std::make_unique();
}
int main(int, char**) {
func();
return 0;
}
I compile with g++-14 -g3 -gdwarf-5 -O2 -c:
readelf --dwarf-check --debug-dump=Ranges
Contents of the .debug_rnglists section:
readelf: Warning: Range lists in .debug_rnglists section start at 0xc
Table at Offset: 0:
Length: 0x5d
DWARF version: 5
Address size:8
Segment size:0
Offset entries: 0
Offset BeginEnd
000c 0024 (base address)
0015 0024 002e
0018 003c 0043
001b
readelf: Warning: There is a hole [0xc - 0x1c] in .debug_rnglists section.
001c 002e (base address)
0025 002e 002e (start == end)
0028 003c 0043
002b
readelf: Warning: There is a hole [0x1c - 0x2c] in .debug_rnglists section.
002c 002e (base address)
0035 002e 003c
0038 0043 004f
003b 0050 0053
003e 0055 005e
0041
readelf: Warning: There is a hole [0x2c - 0x42] in .debug_rnglists section.
0042 0076
004c 0017
0056 000e
0060
(That is the complete output). I can attach the binary, it is 180K in size.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #19 from Sourceware Commits --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=280965fcedbc5e9b683d43cbb49c701071c1015b commit 280965fcedbc5e9b683d43cbb49c701071c1015b Author: Alan Modra Date: Tue Apr 29 09:42:15 2025 +0930 PR 32896 testcase Modify it a little to run on more targets. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32927] readelf --dwarf-check --debug-dump=Ranges produces nonsense warnings for DWARF 4 and DWARF5
https://sourceware.org/bugzilla/show_bug.cgi?id=32927 --- Comment #3 from H.J. Lu --- Created attachment 16060 --> https://sourceware.org/bugzilla/attachment.cgi?id=16060&action=edit A patch Please try this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #11 from H.J. Lu --- (In reply to Matthew Malcomson from comment #10) > (In reply to H.J. Lu from comment #9) > > (In reply to Matthew Malcomson from comment #8) > > > (In reply to H.J. Lu from comment #6) > > > > (In reply to Matthew Malcomson from comment #5) > > > > > I think that this proposed patch could allow putting the PT_TLS > > > > > segment > > > > > offset past the end of the file (that I think was a problem in > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=12921 ). > > > > > > > > > > This because it doesn't adjust the `off` that indicates position into > > > > > the > > > > > file. > > > > > > > > The updated patch is at: > > > > > > > > https://sourceware.org/pipermail/binutils/2025-April/140755.html > > > > > > I had a look at this patch, and it does seem to ensure that the PT_TLS > > > segment has the correct alignment requirements. > > > > > > I noticed that with this patch one can end up with a very large PT_TLS > > > filesize if you re-order the .tbss and .tdata sections. Not sure whether > > > this would be problematic in some way. I did have to use a testcase that > > > was triggering a linker warning so it may be invalid. > > > > > > > Please try > > > > https://sourceware.org/pipermail/binutils/2025-April/140767.html > > > > on the current master branch. > > > That has the same behaviour to do with a large filesz for the PT_TLS segment. > The testcase here makes the .tbss section go before the .tdata section with > an artificial linker script. Please upload your linker script here. A diff doesn't work for me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 H.J. Lu changed: What|Removed |Added Attachment #16053|0 |1 is obsolete|| --- Comment #12 from H.J. Lu --- Created attachment 16054 --> https://sourceware.org/bugzilla/attachment.cgi?id=16054&action=edit A patch Please try this one on the current master branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to link with LTO on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 --- Comment #1 from Quentin Boswank --- The responsible message can be found in elf32-sh.c in a function handling relaxation, R_SH_USES to be exact. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #10 from Matthew Malcomson --- (In reply to H.J. Lu from comment #9) > (In reply to Matthew Malcomson from comment #8) > > (In reply to H.J. Lu from comment #6) > > > (In reply to Matthew Malcomson from comment #5) > > > > I think that this proposed patch could allow putting the PT_TLS segment > > > > offset past the end of the file (that I think was a problem in > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=12921 ). > > > > > > > > This because it doesn't adjust the `off` that indicates position into > > > > the > > > > file. > > > > > > The updated patch is at: > > > > > > https://sourceware.org/pipermail/binutils/2025-April/140755.html > > > > I had a look at this patch, and it does seem to ensure that the PT_TLS > > segment has the correct alignment requirements. > > > > I noticed that with this patch one can end up with a very large PT_TLS > > filesize if you re-order the .tbss and .tdata sections. Not sure whether > > this would be problematic in some way. I did have to use a testcase that > > was triggering a linker warning so it may be invalid. > > > > Please try > > https://sourceware.org/pipermail/binutils/2025-April/140767.html > > on the current master branch. That has the same behaviour to do with a large filesz for the PT_TLS segment. The testcase here makes the .tbss section go before the .tdata section with an artificial linker script. (I needed that order to trick the file size check in `assign_file_positions_for_non_load_sections` since that function will take the starting file position from a NOBITS section but will not take the ending file position from a NOBITS section). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] New: „warning: symbol in unexpected section“
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 Bug ID: 32917 Summary: „warning: symbol in unexpected section“ Product: binutils Version: 2.44 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: qubos at outlook dot de Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to link with LTO on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 Quentin Boswank changed: What|Removed |Added Summary|„warning: symbol in |„warning: symbol in |unexpected section“ |unexpected section“ is ||being spat out when trying ||to link with LTO on SuperH -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to link with LTO on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 Quentin Boswank changed: What|Removed |Added Target||sh4a_nofpu-elf CC||qubos at outlook dot de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #13 from Matthew Malcomson --- Created attachment 16055 --> https://sourceware.org/bugzilla/attachment.cgi?id=16055&action=edit Default AArch64 linker script with slightly modified .tbss/.tdata order As requested, the hacked linker script I used for the "very large PT_TLS segment" edge-case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #14 from Matthew Malcomson --- (In reply to H.J. Lu from comment #12) > Created attachment 16054 [details] > A patch > > Please try this one on the current master branch. It seems to exhibit the same problem. I think it's doing the same as the previous patch -- in my artificial linker script I've re-ordered .tbss and .tdata, which means that the .tbss section is the first one seen. I've just now attached the linker script I used -- the logical difference is that I moved the .tbss output section to before .tdata. I do note that this produces a linker warning, so it might be a not-quite valid testcase. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #9 from H.J. Lu --- (In reply to Matthew Malcomson from comment #8) > (In reply to H.J. Lu from comment #6) > > (In reply to Matthew Malcomson from comment #5) > > > I think that this proposed patch could allow putting the PT_TLS segment > > > offset past the end of the file (that I think was a problem in > > > https://sourceware.org/bugzilla/show_bug.cgi?id=12921 ). > > > > > > This because it doesn't adjust the `off` that indicates position into the > > > file. > > > > The updated patch is at: > > > > https://sourceware.org/pipermail/binutils/2025-April/140755.html > > I had a look at this patch, and it does seem to ensure that the PT_TLS > segment has the correct alignment requirements. > > I noticed that with this patch one can end up with a very large PT_TLS > filesize if you re-order the .tbss and .tdata sections. Not sure whether > this would be problematic in some way. I did have to use a testcase that > was triggering a linker warning so it may be invalid. > Please try https://sourceware.org/pipermail/binutils/2025-April/140767.html on the current master branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #16 from H.J. Lu --- (In reply to Matthew Malcomson from comment #14) > (In reply to H.J. Lu from comment #12) > > Created attachment 16054 [details] > > A patch > > > > Please try this one on the current master branch. > > It seems to exhibit the same problem. > > I think it's doing the same as the previous patch -- in my artificial linker > script I've re-ordered .tbss and .tdata, which means that the .tbss section > is the first one seen. > Please check the updated patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 H.J. Lu changed: What|Removed |Added Attachment #16054|0 |1 is obsolete|| --- Comment #15 from H.J. Lu --- Created attachment 16056 --> https://sourceware.org/bugzilla/attachment.cgi?id=16056&action=edit An updated patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #7 from Sourceware Commits --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5e247da8afb8b764cb111ce1a05e8cb8862a7f98 commit 5e247da8afb8b764cb111ce1a05e8cb8862a7f98 Author: H.J. Lu Date: Mon Apr 28 07:12:48 2025 +0800 elf: Properly set sh_offset for .tbss sections Set sh_offset for .tbss sections to their nominal offset after aligning. They are not loaded from disk so the value doesn't really matter, except when the .tbss section is the first one in a PT_TLS segment. In that case, it sets the p_offset for the PT_TLS segment, which according to the ELF gABI ought to satisfy p_offset % p_align == p_vaddr % p_align. bfd/ PR ld/32896 * elf.c (assign_file_positions_for_load_sections): Properly set sh_offset for .tbss sections. ld/ PR ld/32896 * testsuite/ld-elf/tbss4.d: New file. * testsuite/ld-elf/tbss4.s: Likewise. Signed-off-by: H.J. Lu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896
--- Comment #8 from Matthew Malcomson ---
(In reply to H.J. Lu from comment #6)
> (In reply to Matthew Malcomson from comment #5)
> > I think that this proposed patch could allow putting the PT_TLS segment
> > offset past the end of the file (that I think was a problem in
> > https://sourceware.org/bugzilla/show_bug.cgi?id=12921 ).
> >
> > This because it doesn't adjust the `off` that indicates position into the
> > file.
>
> The updated patch is at:
>
> https://sourceware.org/pipermail/binutils/2025-April/140755.html
I had a look at this patch, and it does seem to ensure that the PT_TLS segment
has the correct alignment requirements.
I noticed that with this patch one can end up with a very large PT_TLS filesize
if you re-order the .tbss and .tdata sections. Not sure whether this would be
problematic in some way. I did have to use a testcase that was triggering a
linker warning so it may be invalid.
vshcmd: > cat tbss-makes-huge-segment.s
# Put enough data into the file to get to the next `maxpagesize`
.section .rodata,"a",@progbits
.align 4
.zero 0x1
.section.tbss,"awT",@nobits
.align 4
.type abc, @object
.size abc, 4
abc:
.zero 4
# Have .tdata and .tbss, so that the
# `assign_file_positions_for_non_load_sections` function takes the file
# position from the two separate sections.
.section .tdata,"awT",@progbits
.align 4
.type val, @object
.size val, 4
val:
.word 13
.text
.global _start
_start:
tls-segfault [11:13:17] $
vshcmd: > # Only difference between default linker script and the one I'm using
vshcmd: > # here is the location of the .tbss section (now before the .tdata
vshcmd: > # section).
vshcmd: > diff segment-too-large.ld \
vshcmd: >
<(../build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-ld
-verbose | sed -n '/=/,/=/p')
> 0a1,10
> ==
> /* Script for -z combreloc */
> /* Copyright (C) 2014-2025 Free Software Foundation, Inc.
>Copying and distribution of this script, with or without modification,
>are permitted in any medium without royalty provided the copyright
>notice and this notice are preserved. */
> OUTPUT_FORMAT("elf64-littleaarch64", "elf64-bigaarch64",
> "elf64-littleaarch64")
> OUTPUT_ARCH(aarch64)
> ENTRY(_start)
> SEARCH_DIR("=/aarch64-none-linux-gnu/lib64");
> SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64");
> SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/aarch64-none-linux-gnu/lib");
> SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
98d107
< .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
103a113
> .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
245a256
> ==
tls-segfault [11:13:20] $
vshcmd: > ../build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-as
\
vshcmd: > tbss-makes-huge-segment.s -o tbss-makes-huge-segment.o
vshcmd: > ../build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-ld
\
vshcmd: > -T segment-too-large.ld \
vshcmd: > tbss-makes-huge-segment.o -o tbss-makes-huge-segment
vshcmd: >
../build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-readelf
--segments --wide tbss-makes-huge-segment
> tls-segfault [11:13:22] $ > >
> ../build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-ld:
> tbss-makes-huge-segment: section .tdata lma 0x42ffe0 adjusted to 0x42ffe4
tls-segfault [11:13:22] $
Elf file type is EXEC (Executable file)
Entry point 0x400120
There are 4 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz
MemSiz Flg Align
LOAD 0x00 0x0040 0x0040 0x010120
0x010120 R 0x1
LOAD 0x01ffe0 0x0042ffe0 0x0042ffe0 0x04
0x04 RW 0x1
TLS0x10 0x0042ffe0 0x0042ffe0 0x01ffd4
0x08 R 0x10
GNU_RELRO 0x10 0x0042ffe0 0x0042ffe0 0x04
0x20 R 0x1
Section to Segment mapping:
Segment Sections...
00 .rodata
01 .tdata
02 .tbss .tdata
03
tls-segfault [11:13:22] $
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to link with LTO on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 --- Comment #2 from Quentin Boswank --- Created attachment 16058 --> https://sourceware.org/bugzilla/attachment.cgi?id=16058&action=edit the actual temp file that gives me the warnings -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32926] New: binutils-gdb ld test with clang toolchain creates infinte looping readelf run
https://sourceware.org/bugzilla/show_bug.cgi?id=32926 Bug ID: 32926 Summary: binutils-gdb ld test with clang toolchain creates infinte looping readelf run Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com Target Milestone: --- Created attachment 16057 --> https://sourceware.org/bugzilla/attachment.cgi?id=16057&action=edit b0rked test input On the fedrawhide buildbot VM, it looks like the binutils-gdb build with the clang toolchain is invoking % readelf --wide --debug-dump=loc tmpdir/dump where the input binary, while cute 6944 byte file, attached, makes even normal f42 readelf go into an infinite loop. That generates an infinite amount of dump text into the buildbot filesystem. (eu-readelf doesn't mind the thing.) https://builder.sourceware.org/buildbot/#/builders/84/builds/3162 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to link with LTO on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 --- Comment #3 from Quentin Boswank --- can confirm that gcc -mrelax gives me the warnings while -Wl,--no-relax does not -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32896] GNU ld does not enforce PT_TLS segment p_offset/p_vaddr congruity with p_align
https://sourceware.org/bugzilla/show_bug.cgi?id=32896 --- Comment #17 from Matthew Malcomson --- (In reply to H.J. Lu from comment #16) > (In reply to Matthew Malcomson from comment #14) > > (In reply to H.J. Lu from comment #12) > > > Created attachment 16054 [details] > > > A patch > > > > > > Please try this one on the current master branch. > > > > It seems to exhibit the same problem. > > > > I think it's doing the same as the previous patch -- in my artificial linker > > script I've re-ordered .tbss and .tdata, which means that the .tbss section > > is the first one seen. > > > > Please check the updated patch. This is at least working for the testcases that I've managed to produce so far. I am vaguely wondering if there's any non-TLS version of the original problem (NOBITS section determining the file offset of a segment) but have not been able to get a testcase for such a thing yet. Hope to have a little more of an attempt towards that tomorrow. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to relax symbols on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 Quentin Boswank changed: What|Removed |Added Summary|„warning: symbol in |„warning: symbol in |unexpected section“ is |unexpected section“ is |being spat out when trying |being spat out when trying |to link with LTO on SuperH |to relax symbols on SuperH -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to link with LTO on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 --- Comment #4 from Quentin Boswank --- found out that it did not needed to be LTO. just that I needed to to apply -mrelax to the compiler instead of the linker -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to relax symbols on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 --- Comment #5 from Quentin Boswank --- Created attachment 16059 --> https://sourceware.org/bugzilla/attachment.cgi?id=16059&action=edit non lto object file this one gives me the warnings when using no lto -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32917] „warning: symbol in unexpected section“ is being spat out when trying to relax symbols on SuperH
https://sourceware.org/bugzilla/show_bug.cgi?id=32917 --- Comment #6 from Quentin Boswank --- the source is a lot smaller for this one. I might be able to recreate a minimal example -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32926] binutils-gdb ld test with clang toolchain creates infinte looping readelf run
https://sourceware.org/bugzilla/show_bug.cgi?id=32926 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.
