[Bug ld/13352] New: microblaze linker relocation bug: R_MICROBLAZE_64_NONE

2011-10-27 Thread bfkeane at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=13352

 Bug #: 13352
   Summary: microblaze linker relocation bug: R_MICROBLAZE_64_NONE
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: bfke...@gmail.com
Classification: Unclassified


Created attachment 6037
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6037
Tarball contains two C source files. Please compile and link as described
above.

In certain cases the mb-gcc linker doesn't update the IMM operand when address
mode optimization (a.k.a. relaxation, ld -relax) shrinks a R_MICROBLAZE_64_NONE
relocation. I believe the assembler generates this relocation type for a BRLID
to a function declared static in the same module. If the relocation target in
the BRLID instruction is further than 64kbytes away _before_ relaxation (i.e.
on output from the assembler) but changes to less than 64Kbytes away _after_
relaxation, the linker updates the BRLID immediate operand but fails to update
the IMM operand.

Note this only happens when an input .o is fairly large (at least 64KB of
.text).

One workaround is to invoke ld directly and omit the -relax option.

I'm using Xilinx EDK 12.4. "mb-gcc -v" says:
gcc version 4.1.2 20070214 (Xilinx 12.3 Build EDK_MS3.66 14 Jul 2010)

To reproduce the problem:

1) unpack the two source files from the attached tarball
2) mb-gcc -v -mcpu=v8.00.b -mno-xl-soft-mul -O -o relax relax.c relax2.c
3) mb-objdump -d relax | grep brlid | grep -v '//'

The last command will print the line of the badly-linked subroutine call.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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/13352] microblaze linker relocation bug: R_MICROBLAZE_64_NONE

2011-10-27 Thread bfkeane at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=13352

--- Comment #1 from Barry Keane  2011-10-27 17:40:17 
UTC ---
I should clarify a little more. The problematic IMM+BRLID instruction pair lies
at text addresses 0x100A8 and 0x100AC in the linker output.

   100a8:   b000fffeimm -2
   100ac:   b9f4015cbrlid   r15, 348

The target subroutine address (atoi) lies at 0x0208.
The BRLID interprets its address as a PC-relative (not absolute) address, hence
the linker relocation result should be the difference:
atoi address: 0x208:
BRLID address: 0x100AC
difference:  0x015C 
Instead the linker produces 0xFFFE015C, which is a bug.

If you look at the .o assembler output you'll see that that the assembler
produces a correct PC-relative address in which the IMM operand is 0xFFFE.

   10270:   b000fffeimm -2
   10274:   b9f4fd8cbrlid   r15, -628   // 0 

At this point (before relaxation) the target is more than 64KB away from the
BRLID instruction: 0xFFFEFD8C (66164 decimal) bytes. After relaxation the
target is less than 64KB away: 0x015C (65188 decimal) bytes.

It looks to me like the linker's relaxation optimization updated the BRLID
operand but neglected to update the IMM operand.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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/13352] microblaze linker relocation bug: R_MICROBLAZE_64_NONE

2011-10-27 Thread bfkeane at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=13352

Barry Keane  changed:

   What|Removed |Added

 CC||bfkeane at gmail dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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