[Bug ld/22751] LTO broken for libgcc libcalls
https://sourceware.org/bugzilla/show_bug.cgi?id=22751 --- Comment #3 from Alan Modra --- Reverting 1fa4ec6ae7 makes no difference. Indeed, now that I've refreshed my memory on what that patch does, it should not since all it is doing (or at least supposed to be doing!) is reordering the layout of object files. Opening objects, adding their symbols and deciding whether they need including happens before ld gets to the new 1fa4ec6ae7 code.. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22751] LTO broken for libgcc libcalls
https://sourceware.org/bugzilla/show_bug.cgi?id=22751 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22751] LTO broken for libgcc libcalls
https://sourceware.org/bugzilla/show_bug.cgi?id=22751 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC|amodra at gmail dot com| Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #2 from Alan Modra --- Uggh. I guess we need to implement the comment I made. "Ideally the recompiled objects ought to be ordered to the same place their IR objects were." -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22751] LTO broken for libgcc libcalls
https://sourceware.org/bugzilla/show_bug.cgi?id=22751 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22741] objcopy segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=22741 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-26 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22751] LTO broken for libgcc libcalls
https://sourceware.org/bugzilla/show_bug.cgi?id=22751 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- The problem is --whole-archive libx.a --no-whole-archive -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ld rescan order is wrong. It rescans -lgcc_s before x.ltrans0.ltrans.o from libx.a. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22750] .sizeof. directive is handled incorrectly in shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=22750 H.J. Lu changed: What|Removed |Added CC||amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22750] .sizeof. directive is handled incorrectly in shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=22750 --- Comment #1 from H.J. Lu --- The problem is Relocation section '.rela.data' at offset 0x100 contains 1 entry: Offset Info Type Sym. ValueSym. Name + Addend 00050001 R_X86_64_64 .sizeof.__verbose + 0 Relocation against .sizeof.__verbose is very special. It is handled incorrectly in shared object. Given that the ".sizeof." directive is never intended to be used in shared object, should we just simply disallow it in shared object? If we do that, do we still need commit 32253bb7963ac7caa166ec41e336372f2ffc03d4 Author: Alan Modra Date: Tue Jan 23 10:50:02 2018 +1030 Define __start/__stop symbols when there is only a dynamic def This patch fixes a case where a user had a C-representable named section in both the executable and shared libraries, and of course wanted the size of the local section in the executable, not the dynamic section. It does mean that __start and __stop symbols don't behave exactly like PROVIDEd symbols, but I think that's a reasonable difference particularly since this is the way they used to behave. * elflink.c (bfd_elf_define_start_stop): Override symbols when they are defined dynamically. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22750] New: .sizeof. directive is handled incorrectly in shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=22750
Bug ID: 22750
Summary: .sizeof. directive is handled incorrectly in shared
object
Product: binutils
Version: 2.31 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-6 sizeof-3]$ cat pr21964-3a.c
#include
extern int __start___verbose[];
extern int __stop___verbose[];
extern intptr_t sizeof___verbose __attribute__ ((visibility ("hidden")));
int
foo1 (void)
{
static int my_var[5] __attribute__((used, section("__verbose")))
= { 5, 4, 3, 2, 1 };
if (__start___verbose == __stop___verbose
|| __start___verbose[0] != 5
|| sizeof___verbose != (5 * sizeof (int)))
return -1;
else
return 0;
}
[hjl@gnu-6 sizeof-3]$ cat pr21964-3b.c
#include
extern int __start___verbose[];
extern int __stop___verbose[];
extern intptr_t sizeof___verbose __attribute__ ((visibility ("hidden")));
int
foo2 (void)
{
static int my_var[10] __attribute__((used, section("__verbose")))
= { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 };
if (__start___verbose == __stop___verbose
|| __start___verbose[0] != 10
|| sizeof___verbose != (10 * sizeof (int)))
return -1;
else
return 0;
}
[hjl@gnu-6 sizeof-3]$ cat pr21964-3c.c
#include
#include
extern int foo1 (void);
extern int foo2 (void);
extern int __start___verbose[];
extern int __stop___verbose[];
static int my_var[6] __attribute__((used, section("__verbose")))
= { 6, 4, 3, 2, 1 };
extern intptr_t sizeof___verbose __attribute__ ((visibility ("hidden")));
int
bar (void)
{
if (__start___verbose == __stop___verbose)
return -1;
if (__start___verbose[0] != 6
|| sizeof___verbose != (6 * sizeof (int)))
return -2;
else
return 0;
}
int
main ()
{
if (bar () == 0
&& foo1 () == 0
&& foo2 () == 0)
printf ("PASS\n");
else
printf ("FAIL\n");
return 0;
}
[hjl@gnu-6 sizeof-3]$ cat pr21964-3d.s
.data
.align 8
.ifdef UNDERSCORE
.globl _sizeof___verbose
.type _sizeof___verbose, %object
_sizeof___verbose:
.dc.a .sizeof. (__verbose)
.size _sizeof___verbose, .-_sizeof___verbose
.else
.globl sizeof___verbose
.type sizeof___verbose, %object
sizeof___verbose:
.dc.a .sizeof. (__verbose)
.size sizeof___verbose, .-sizeof___verbose
.endif
[hjl@gnu-6 sizeof-3]$ make
gcc -B./ -g -c -o pr21964-3c.o pr21964-3c.c
as -o pr21964-3d.o pr21964-3d.s
gcc -B./ -g -fPIC -c -o pr21964-3a.o pr21964-3a.c
./ld -shared -o pr21964-3a.so pr21964-3a.o pr21964-3d.o
gcc -B./ -g -fPIC -c -o pr21964-3b.o pr21964-3b.c
./ld -shared -o pr21964-3b.so pr21964-3b.o pr21964-3d.o
gcc -B./ -o pr21964-3 pr21964-3c.o pr21964-3d.o pr21964-3a.so pr21964-3b.so
-Wl,-R,.
./pr21964-3
FAIL
[hjl@gnu-6 sizeof-3]$
[hjl@gnu-6 sizeof-3]$ gdb ./pr21964-3
GNU gdb (GDB) Fedora 8.0.1-35.0.fc27
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
[Bug ld/22751] New: LTO broken for libgcc libcalls
https://sourceware.org/bugzilla/show_bug.cgi?id=22751
Bug ID: 22751
Summary: LTO broken for libgcc libcalls
Product: binutils
Version: 2.30
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jcowgill+sourceware at jcowgill dot uk
Target Milestone: ---
From:
https://bugs.debian.org/888478
LD 2.30 seems to mishandle libcalls into libgcc when LTO is enabled.
Testcase for 64-bit architectures (test.c):
volatile __int128 a = 42;
volatile __int128 b = 1;
int main(void)
{
return (int) (a / b);
}
For 32-bit:
volatile unsigned long long a = 42;
volatile unsigned long long b = 1;
int main(void)
{
return (int) (a / b);
}
Compile with:
gcc -flto -O2 -c test.c
ar rcs libtest.a test.o
gcc -flto -Wl,--whole-archive libtest.a -Wl,--no-whole-archive
[The --whole-archive is not needed in general, but is for this test case]
On x86_64 this gives:
/usr/bin/ld: /tmp/cc8wkDcQ.ltrans0.ltrans.o(.text.startup+0x21): unresolvable
R_X86_64_PLT32 relocation against symbol `__divti3'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
On i386:
/usr/bin/ld: /tmp/cc5ZOEfW.ltrans0.ltrans.o(.text.startup+0x3d): unresolvable
R_386_PLT32 relocation against symbol `__udivdi3'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
On mipsel (o32 little endian):
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail
../../bfd/elflink.c:9757
collect2: error: ld returned 1 exit status
I managed to bisect this (on x86_64) to:
1fa4ec6ae707402c6b61cde33cfe4bdeafd53f82 is the first bad commit
commit 1fa4ec6ae707402c6b61cde33cfe4bdeafd53f82
Author: Alan Modra
Date: Sat Sep 2 11:08:05 2017 +0930
LTO rescan archives
ld ought to be more clever about where it puts LTO recompiled objects.
Ideally the recompiled objects ought to be ordered to the same place
their IR objects were, and files extracted from archives on the second
pass ought to go in the same place as they would if extracted on the
first pass. This patch addresses the archive problem. Without this
fix, objects extracted from archives might be placed after the crt
files intended to go at the end of an executable or shared library,
possibly causing exception handling failures.
* ldlang.h (lang_input_statement_type): Expand comments.
(LANG_FOR_EACH_INPUT_STATEMENT): Rewrite without casts.
* ldlang.c (lang_for_each_input_file): Likewise.
(load_symbols): Set usrdata for archives.
(find_rescan_insertion): New function.
(lang_process): Trim off and reinsert entries added to file chain
when rescanning archives for LTO.
* ldmain.c (add_archive_element): Set my_archive input_statement
next pointer to last element added.
:04 04 933c913523934e7984e5f291b407014374cc5aa8
41866e5eae1ab88e83ba47561d9dbbede3ff4231 M ld
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22749] Bad alignment and padding of .note.gnu.property
https://sourceware.org/bugzilla/show_bug.cgi?id=22749
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #1 from H.J. Lu ---
(In reply to Mark Wielaard from comment #0)
> The .note.gnu.property SHT_NOTE uses wrong alignment and padding on
> ELFCLASS64. This breaks note parsers which will see garbage data inside a
> NOTE and might flag the ELF file as invalid or stop parsing any note data
> (since they cannot know how to skip the note).
>
> Unlike what gabi says, GNU always uses 4 byte alignment and padding, plus
> 32bit sizes for namesz and descrsz in notes independent from ELF class.
>
> gabi says to use 8 byte alignment and padding, plus 64bit sizes for
> ELFCLASS64, but others (except HPUX it seems) also don't follow that. Nobody
> uses 8 byte alignment/padding and 32bit sizes.
>
> This was discussed on the gnu-gabi and gabi mailinglists:
> https://sourceware.org/ml/gnu-gabi/2017-q4/msg00028.html
>
> Proposed fix:
>
> diff --git a/bfd/elf-properties.c b/bfd/elf-properties.c
> index 2549dd0..647931b 100644
> --- a/bfd/elf-properties.c
> +++ b/bfd/elf-properties.c
> @@ -394,7 +394,8 @@ _bfd_elf_link_setup_gnu_properties (struct bfd_link_info
> *info)
>unsigned int descsz;
>bfd_byte *contents;
>Elf_External_Note *e_note;
> - unsigned int align_size = bed->s->elfclass == ELFCLASS64 ? 8 : 4;
> + /* Note GNU SHT_NOTEs are always 4 byte aligned. */
> + unsigned int align_size = 4;
>
According to gABI, SHT_NOTE should be aligned to ELFCLASS64.
In any case, you can check note alignment by looking up the
alignment field in its header. In elf.c, there are
static bfd_boolean
elf_parse_notes (bfd *abfd, char *buf, size_t size, file_ptr offset,
size_t align)
{
char *p;
/* NB: CORE PT_NOTE segments may have p_align values of 0 or 1.
gABI specifies that PT_NOTE alignment should be aligned to 4
bytes for 32-bit objects and to 8 bytes for 64-bit objects. If
align is less than 4, we use 4 byte alignment. */
if (align < 4)
align = 4;
These tools can be updated to follow gABI without breaking backward
compatibility.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22749] New: Bad alignment and padding of .note.gnu.property
https://sourceware.org/bugzilla/show_bug.cgi?id=22749
Bug ID: 22749
Summary: Bad alignment and padding of .note.gnu.property
Product: binutils
Version: 2.31 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: mark at klomp dot org
Target Milestone: ---
The .note.gnu.property SHT_NOTE uses wrong alignment and padding on ELFCLASS64.
This breaks note parsers which will see garbage data inside a NOTE and might
flag the ELF file as invalid or stop parsing any note data (since they cannot
know how to skip the note).
Unlike what gabi says, GNU always uses 4 byte alignment and padding, plus 32bit
sizes for namesz and descrsz in notes independent from ELF class.
gabi says to use 8 byte alignment and padding, plus 64bit sizes for ELFCLASS64,
but others (except HPUX it seems) also don't follow that. Nobody uses 8 byte
alignment/padding and 32bit sizes.
This was discussed on the gnu-gabi and gabi mailinglists:
https://sourceware.org/ml/gnu-gabi/2017-q4/msg00028.html
Proposed fix:
diff --git a/bfd/elf-properties.c b/bfd/elf-properties.c
index 2549dd0..647931b 100644
--- a/bfd/elf-properties.c
+++ b/bfd/elf-properties.c
@@ -394,7 +394,8 @@ _bfd_elf_link_setup_gnu_properties (struct bfd_link_info
*info)
unsigned int descsz;
bfd_byte *contents;
Elf_External_Note *e_note;
- unsigned int align_size = bed->s->elfclass == ELFCLASS64 ? 8 : 4;
+ /* Note GNU SHT_NOTEs are always 4 byte aligned. */
+ unsigned int align_size = 4;
sec = bfd_get_section_by_name (first_pbfd,
NOTE_GNU_PROPERTY_SECTION_NAME);
diff --git a/bfd/elfxx-x86.c b/bfd/elfxx-x86.c
index a7db5d9..e6d45f3 100644
--- a/bfd/elfxx-x86.c
+++ b/bfd/elfxx-x86.c
@@ -2424,7 +2424,12 @@ _bfd_x86_elf_link_setup_gnu_properties
if (sec == NULL)
info->callbacks->einfo (_("%F%P: failed to create GNU property
section\n"));
- if (!bfd_set_section_alignment (ebfd, sec, class_align))
+ /* GNU ABI always aligns and pads SHT_NOTES 4 bytes. Using
+ 32bit sizes for name_sz and desc_sz. Independent from
+ the ELF class. This is different from gabi, which uses
+ alignement and padding of 8 bytes, plus 64bit sizes for
+ ELFCLASS64. Changing this breaks existing NOTE parsers. */
+ if (!bfd_set_section_alignment (ebfd, sec, 2))
{
error_alignment:
info->callbacks->einfo (_("%F%A: failed to align section\n"),
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
