bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/25599] New: gas generates invalid PCREL60B relocation offset wi


From: peter.bisroev at groundlabs dot com
Subject: [Bug gas/25599] New: gas generates invalid PCREL60B relocation offset with brl.call
Date: Tue, 25 Feb 2020 16:22:52 +0000

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

            Bug ID: 25599
           Summary: gas generates invalid PCREL60B relocation offset with
                    brl.call
           Product: binutils
           Version: 2.32
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: peter.bisroev at groundlabs dot com
                CC: dave.anglin at bell dot net
  Target Milestone: ---

Created attachment 12322
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12322&action=edit
Code and binaries that display this bug.

Hi Everyone,

While attempting to help bootstrap a recent version of gcc on HP-UX IA-64
platform (GCC bug 61577 comments 202, 203 and 204), we have hit a PCREL60B
reloc related issue.

The following tools were used:
- HP-UX B.11.31 (IA-64)
- GCC 4.7.4
- Binutils 2.32 (but this happens with 2.34 as well)
- 92453-07 linker ld HP Itanium(R) B.12.65  IPF/IPF

In the attachment binutils-gas-PCREL60B-bug.tgz you will find all the code as
well as binaries used to trigger and demonstrate this issue. The source
main-brl.s was generated by taking the output of compiling main.c with
-save-temps option and changing br.call to brl.call, this source is presented
below:
------------------------------
        .file   "main.c"
        .pred.safe_across_calls p1-p5,p16-p63
        .section        .text,  "ax",   "progbits"
        .align 16
        .global main#
        .type   main#, @function
        .proc main#
main:
        .prologue 14, 32
        .save ar.pfs, r33
        alloc r33 = ar.pfs, 0, 4, 0, 0
        .vframe r34
        mov r34 = r12
        .save rp, r32
        mov r32 = b0
        mov r35 = r1
        .body
        ;;
        brl.call.sptk.many b0 = hello#
        mov r1 = r35
        mov r14 = r0
        ;;
        mov r8 = r14
        mov ar.pfs = r33
        mov b0 = r32
        .restore sp
        mov r12 = r34
        br.ret.sptk.many b0
        ;;
        .endp main#
        .global hello#
        .type   hello#, @function
        .ident  "GCC: (GNU) 4.7.4"
------------------------------

When assembling main-brl.s we get the expected PCREL60B relocation but at the
wrong offset (0x21 instead of 0x22):
------------------------------
20:   04 00 00 00 01 00       [MLX]       nop.m 0x0
                      21: PCREL60B    hello
26:   00 00 00 00 00 00                   brl.call.sptk.many b0=20 <main+0x20>
------------------------------

If we now link this object into the final executable HP's linker clobbers the
nop.m at 0x20 due to the wrong reloc offset as shown below:
------------------------------
4000930:       04 00 00 00 00 00       [MLX]       break.m 0x0
4000936:       00 30 00 00 00 00                   brl.call.sptk.many
b0=4000930 <_end+0xc3ff08f0>
400093c:       08 00 00 d0 
------------------------------

This seems to be the only issue here. To verify I checked the 60 bit immediate
that gets encoded and it seems to be correct. I have also manually patched
main-brl.o to change the reloc offset from 0x21 to 0x22 and relinked as shown
below:
------------------------------
# objdump -rd main-brl-patched.o
20:   04 00 00 00 01 00       [MLX]       nop.m 0x0
                      22: PCREL60B    hello
26:   00 00 00 00 00 00                   brl.call.sptk.many b0=20 <main+0x20>


# objdump -rd hello-brl-patched
4000930:       04 00 00 00 01 00       [MLX]       nop.m 0x0
4000936:       00 00 00 00 00 00                   brl.call.sptk.many
b0=4000990 <hello>
400093c:       68 00 00 d0 
------------------------------

As can be seen above the relocation is now correct and the executable works as
expected.

Please let me know if further info is required.

Thank you!
--peter

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]