[Bug binutils/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24768

--- Comment #2 from Alan Modra  ---
+/* This a copy of lto_section defined in GCC (lto-streamer.h).  */
+
+struct lto_section
+{
+  int16_t major_version;
+  int16_t minor_version;
+  unsigned char slim_object: 1;
+  unsigned int compression: 4;
+  int32_t reserved0: 27;
+};
+

The layout of this struct depends on the host compiler.  Won't that cause
problems in object file portability?

-- 
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/24806] New: Linking with unclosed -start-group and -T init.ld creates incorrect result

[ohngeonocaewoungooth at xff dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=24806

Bug ID: 24806
   Summary: Linking with unclosed -start-group and -T init.ld
creates incorrect result
   Product: binutils
   Version: 2.33 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: ohngeonocaewoungooth at xff dot cz
  Target Milestone: ---

Created attachment 11906
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11906&action=edit
Tar file with files to reproduce the good/bad binaries

If I link with '-T init.ld' and a unclosed -start-group:

--
SECTIONS
{
.tools :
{
tool_entries = .;
*(.tools)
LONG(0)
LONG(0)
}
}
INSERT AFTER .debug;


The tools section will be placed differently than if I don't use -start-group
or close it explicitly.

objdump -h prints:

--

bad: file format elf64-x86-64

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .tools0020      1000  2**0
  CONTENTS, ALLOC, LOAD, DATA
 ... [snip] ...

--

good: file format elf64-x86-64

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
 ... [snip] ...
 25 .tools0020  6060  6060  3060  2**0
  CONTENTS, ALLOC, LOAD, DATA
--

This leads to a non-working executable. I've attached a complete test case.

-- 
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/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24784

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from H.J. Lu  ---
(In reply to Fangrui Song from comment #3)
> This was discovered by a Rust user. They use clang integrated assembler (not
> GNU as) with GNU ld. The integrated assembler isn't configured with
> -Wa,-mrelax-relocations=yes on by default. I worked around that in
> https://reviews.llvm.org/D64304 but it'd be nice if binutils 2.33 (or 2.34)
> will fix the issue.

The bug should be fixed in clang.

-- 
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/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)

[maskray at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24784

--- Comment #5 from Fangrui Song  ---
I don't see how this bug is "invalid". I've already worked around the bug in
clang, but I hope this hack can be deleted in a few years.

> g++ -fno-plt -fpic a.cc -Wa,-mrelax-relocations=no -fuse-ld=bfd

I mentioned the combination of -fno-plt and -Wa,-mrelax-relocations=no doesn't
work. So we have 3 resolutions:

1. Ignore it.
  gcc -fno-plt -fpic -Wa,-mrelax-relocations=no  has the linker error
2. Document in Chapter 11 Alternate Code Sequences For Security of x86-64
psABI,
  call *__tls_get_addr@GOTPCREL(%rip)
  must use R_X86_64_GOTPCRELX.

  This kinda justifies 1., though it is not obvious why R_X86_64_GOTPCREL can't
be used.
3. One line change to bfd/elf-x86-64.c:elf_x86_64_check_tls_transition
- return r_type == R_X86_64_GOTPCRELX; // It should allow R_X86_64_GOTPCREL
+ return r_type == R_X86_64_GOTPCREL || r_type == R_X86_64_GOTPCRELX;
 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9b3777ae068e67e08b27914abbab11297f1f8d1b

With 3, the `gcc -fno-plt -fpic -Wa,-mrelax-relocations=no` issue can be fixed.

-- 
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