[Bug ld/20868] ld relaxes TLS access erroneously for aarch64 in ilp32 mode

[ynorov at caviumnetworks dot com]

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

--- Comment #4 from Yury Norov  ---
(In reply to Jiong Wang from comment #3)
> Hi Yury,
> 
> Some quick thoughts:
> 
> >   
> > But in executalbe binary ld relaxes tls access with direct address
> > calculation:
> > 279 register unsigned long __result asm ("w0");
> > 280 asm volatile ("adrp %0, :tlsgd:foo; \n"
> > 281   400618:   9080adrpx0, 41 
> > <__FRAME_END__+0xf828>
> > 282   40061c:   f948ec00ldr x0, [x0,#4568]
> > 283   400620:   d53bd041mrs x1, tpidr_el0
> > 284   400624:   8b20add x0, x1, x0
> 
> The sequences is still loading tls offset from GOT table, then add it to the
> tp.  It seems to me be a GD->IE bug on ILP32.
> 
> Can you try to modify 0xf940 to 0xb940 in elfNN_aarch64_tls_relax
> when relaxing BFD_RELOC_AARCH64_TLSGD_ADD_LO12_NC, does it work for you?
> 
> The "ldr x0, [x0,#4568]" looks suspicous to me.  the x0 implies 8bytes
> scale, while ILP32 relocations are doing 4bytes shift.

To me too.

This code replaces TLS access with GOT using "ldr w0, [x0, ...]" manually, and
it works:
register unsigned long __result asm ("w0");
//  asm volatile ("adrp %0, :tlsgd:foo; \n"
//  "add %w0, %w0, #:tlsgd_lo12:foo; \n"
//  "bl my_tls_get_addr;\n"
//  "nop\n"
//  : "=r" (__result)
//  :
//  : "x1", "x2", "x3", "x4", "x5", "x6", "x7",
//  "x8", "x9", "x10", "x11", "x12", "x13",
//  "x14", "x15", "x16", "x17", "x18", "x30",
//  "memory", "cc");
asm volatile ("adrp %0, :gottprel:foo; \n"
"ldr %w0, [%0, #:gottprel_lo12:foo];\n"
"mrs x1, tpidr_el0;\n"
"add %w0, w1, %w0\n"
: "=r" (__result)
:
: "x1", "x2", "x3", "x4", "x5", "x6", "x7",
"x8", "x9", "x10", "x11", "x12", "x13",
"x14", "x15", "x16", "x17", "x18", "x30",
"memory", "cc");
bp = (unsigned int *) __result;
printf ("TLS_LD == %p\n", bp);
printf ("*TLS_LD == %d\n", *bp);

I can prepare the patch for binutils, but I need some time to setup environment
and get into the code. If you find it urgent, you'd better do it by yourself

-- 
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 gold/20870] New: Cannot use gold linker together with free pascal

[denisgolovan at yandex dot ru]

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

Bug ID: 20870
   Summary: Cannot use gold linker together with free pascal
   Product: binutils
   Version: 2.25
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: denisgolovan at yandex dot ru
CC: ian at airs dot com
  Target Milestone: ---

Created attachment 9670
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9670=edit
sources and logs

Hi

For some reason, even the simplest project for FreePascal cannot be linked
using gold linker. See attachment for details.

Tested under binutils-2.25.1 Gentoo x64.

-- 
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/20868] ld relaxes TLS access erroneously for aarch64 in ilp32 mode

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.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 ld/20868] ld relaxes TLS access erroneously for aarch64 in ilp32 mode

[jiwang at gcc dot gnu.org]

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

--- Comment #3 from Jiong Wang  ---
Hi Yury,

Some quick thoughts:

>   
> But in executalbe binary ld relaxes tls access with direct address
> calculation:
> 279 register unsigned long __result asm ("w0");
> 280 asm volatile ("adrp %0, :tlsgd:foo; \n"
> 281   400618:   9080adrpx0, 41 <__FRAME_END__+0xf828>
> 282   40061c:   f948ec00ldr x0, [x0,#4568]
> 283   400620:   d53bd041mrs x1, tpidr_el0
> 284   400624:   8b20add x0, x1, x0

The sequences is still loading tls offset from GOT table, then add it to the
tp.  It seems to me be a GD->IE bug on ILP32.

Can you try to modify 0xf940 to 0xb940 in elfNN_aarch64_tls_relax when
relaxing BFD_RELOC_AARCH64_TLSGD_ADD_LO12_NC, does it work for you?

The "ldr x0, [x0,#4568]" looks suspicous to me.  the x0 implies 8bytes
scale, while ILP32 relocations are doing 4bytes shift.

-- 
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/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix

[james410 at cowgill dot org.uk]

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

--- Comment #10 from James Cowgill  ---
(In reply to Maciej W. Rozycki from comment #8)
> By the MIPS psABI's definition you shall not have external GGA_NONE
> symbols as any GGA_NONE symbols will be assigned to the local GOT part,
> whose entries are only relocated by the base address at the load time.
> Symbols in the GGA_NONE class will normally not have dynsym entries,
> except from selected section symbols.

The psABI says:
The dynamic symbol table, like all ELF symbol tables, is divided into local and
global parts. The global part of the dynamic symbol table is further divided
into two parts: symbols that do not have GOT entries associated with them and
symbols that do have GOT entries associated with them.

Surly this implies that it is legitimate for an external symbol to be GGA_NONE?
The case illustrated here where a symbol is defined but not used within a
shared library seems like a good use case for this.

Since LOCAL symbols must be GGA_NONE, the local symbol handler in my patch
could probably be simplified a little.

[...]
> I agree the presence of (non-section) local symbols in the dynsym table
> is a generic issue, and given that `elf_gc_sweep_symbol' appears to be
> the only place where they are created I think that rather than
> adjusting this piece of code to assign these symbols to the GGA_NONE
> class it will make sense to discard them altogether.  Unless there is
> an actual need for them, that is, which I yet need to be told about.
> FAOD it is not incorrect to have them -- it is just useless.

It breaks the ld-elf/provide-hidden testcase, but that can be adjusted to not
look for local dynamic symbols. This patch implements what you suggest
(dropping symbols defined in the linker script dynamic symbol table if they are
definitely local) and on its own fixes this bug as well.

--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -669,7 +669,8 @@ bfd_elf_record_link_assignment (bfd *output_bfd,
|| h->ref_dynamic
|| bfd_link_dll (info)
|| elf_hash_table (info)->is_relocatable_executable)
-  && h->dynindx == -1)
+  && h->dynindx == -1
+  && h->forced_local == 0)
 {
   if (! bfd_elf_link_record_dynamic_symbol (info, h))
return FALSE;

-- 
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/20868] ld relaxes TLS access erroneously for aarch64 in ilp32 mode

[jiwang at gcc dot gnu.org]

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

--- Comment #2 from Jiong Wang  ---
(In reply to Jiong Wang from comment #1)
> I investigate this.

-> I will investigate this.

-- 
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/20868] ld relaxes TLS access erroneously for aarch64 in ilp32 mode

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-25
 CC||jiwang at gcc dot gnu.org
   Assignee|unassigned at sourceware dot org   |jiwang at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jiong Wang  ---
I investigate this.

-- 
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/20868] New: ld relaxes TLS access erroneously for aarch64 in ilp32 mode

[ynorov at caviumnetworks dot com]

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

Bug ID: 20868
   Summary: ld relaxes TLS access erroneously for aarch64 in ilp32
mode
   Product: binutils
   Version: 2.24
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: ynorov at caviumnetworks dot com
  Target Milestone: ---

Created attachment 9669
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9669=edit
test to reproduce the bug

ld -v:
GNU ld (Cavium Inc. Version 0.99 build 428) 2.24.51.20140823

asm volatile() snippet:
register unsigned long __result asm ("w0");
asm volatile ("adrp %0, :tlsgd:foo; \n"
"add %w0, %w0, #:tlsgd_lo12:foo; \n"
"bl my_tls_get_addr;\n"
"nop\n"
: "=r" (__result)
:
: "x1", "x2", "x3", "x4", "x5", "x6", "x7",
"x8", "x9", "x10", "x11", "x12", "x13",
"x14", "x15", "x16", "x17", "x18", "x30",
"memory", "cc");
bp = (unsigned int *) __result;

The code above generates next assembly in object file: 
register unsigned long __result asm ("w0");
asm volatile ("adrp %0, :tlsgd:foo; \n"
  c8:   9000adrpx0, 4 
  cc:   1100add w0, w0, #0x0
  d0:   9400bl  0 
  d4:   d503201fnop
:
: "x1", "x2", "x3", "x4", "x5", "x6", "x7",
"x8", "x9", "x10", "x11", "x12", "x13",
"x14", "x15", "x16", "x17", "x18", "x30",
"memory", "cc");
bp = (unsigned int *) __result;
  d8:   2a0003e7mov w7, w0
  dc:   b9001ba7str w7, [x29,#24]

But in executalbe binary ld relaxes tls access with direct address calculation:
279 register unsigned long __result asm ("w0");
280 asm volatile ("adrp %0, :tlsgd:foo; \n"
281   400618:   9080adrpx0, 41 <__FRAME_END__+0xf828>
282   40061c:   f948ec00ldr x0, [x0,#4568]
283   400620:   d53bd041mrs x1, tpidr_el0
284   400624:   8b20add x0, x1, x0
285 :
286 : "x1", "x2", "x3", "x4", "x5", "x6", "x7",
287 "x8", "x9", "x10", "x11", "x12", "x13",
288 "x14", "x15", "x16", "x17", "x18", "x30",
289 "memory", "cc");
290 bp = (unsigned int *) __result;
291   400628:   2a0003e7mov w7, w0
292   40062c:   b9001ba7str w7, [x29,#24]

So ld detects the access to tls that it can optimize, but does it wrong -
actual address is less that expected by 8. In lp64 mode ld does the same, but
the result is correct.

Full test source is attached.

-- 
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/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix

[james410 at cowgill dot org.uk]

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

--- Comment #9 from James Cowgill  ---
I added some debug code ontop of my patch and it seems that at the time the
dynamic symbol table indexes are allocated, all the symbols are GGA_NONE.

debug: _fdata, LOCAL, GGA_NONE
debug: _ftext, LOCAL, GGA_NONE
debug: __bss_start, LOCAL, GGA_NONE
debug: _edata, LOCAL, GGA_NONE
debug: _end, LOCAL, GGA_NONE
debug: _fbss, LOCAL, GGA_NONE
debug: psi, GLOBAL, GGA_NONE
debug: omega, GLOBAL, GGA_NONE

Even when --gc-sections is removed all the symbols are GGA_NONE (although they
are all now GLOBAL). Clearly at least psi and omega are external symbols.

If I adjust stubs.c a bit, it seems a symbol is only ever GGA_NORMAL if it
actually needs a GOT entry (eg if I call psi from omega, psi becomes GGA_NORMAL
but omega remains GGA_NONE).

-- 
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/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Nick Clifton  ---
Hi JOo,

> Here's the alternate approach, of not allowing the .rsrc section to shrink.
> 
> This seems to work ok (all the output .exe in my test case are valid), but
> this can waste a page in the output file (with the default manifest,
> potentially more if non-trivial resource sections were merged)

Wasting a page seems like a small price to pay in order to gain working
executables.  So I have checked your patch in.

Cheers
  Nick

-- 
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/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Clifton :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ec8f76882145c71bef81a9cadf0bf51ff9fa5b35

commit ec8f76882145c71bef81a9cadf0bf51ff9fa5b35
Author: Jon Turney 
Date:   Fri Nov 25 09:47:31 2016 +

Prevent problems with section alignment by not shrinking the .rsrc section.

PR ld/20193
* peXXigen.c (rsrc_process_section): Do not shrink the merged
.rsrc section.

-- 
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/20866] New: "-z combreloc" doesn't work on alpha

[alpha at culzean dot org]

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

Bug ID: 20866
   Summary: "-z combreloc" doesn't work on alpha
   Product: binutils
   Version: 2.27
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: alpha at culzean dot org
  Target Milestone: ---

This problem may have been caused by the following change.

"Set dynamic tag VMA and size from dynamic section when possible"
2016/05/13 11:18
4ade44b727ee77adaa9c22719935d012e253a5e6

It's changed so that dynobj is passed to bfd_get_linker_section in
elf64-alpha.c.
If output_bfd is passed, this problem doesn't occur.

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