[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
peter.bisroev at groundlabs dot com
gcc-bugzilla@gcc.gnu.org
Thu Feb 13 18:12:00 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #172 from Peter Bisroev <peter.bisroev at groundlabs dot com> ---
Hi Dave,
(In reply to dave.anglin from comment #168)
> There seems to be something broken regarding stub insertion for calls to
> weak functions. Are we
> using the correct branch form for calls to weak? There doesn't seem to be a
> problem with branches
> to functions that aren't defined in the module.
>
> Could you try compiling sancov.c from gcc-8 with aCC in C++ mode. Use -S to
> get assembler output.
> What happens to weak calls (e.g., the one I pointed out previously)?
Unfortunately as mentioned in comment 165 I was unable to get aCC to compile
sancov.c from gcc 8.3.0 or use HP's assember with gcc generated .s output.
However I was able to reproduce the same relocation issue when attempting to
compile gcc 4.9.4 and at the same time was able to compile one of the
problematic files (gimple-expr.c) with aCC as well.
I have attached relevant results as you have requested in attachment 47828. But
I did not see the relevant functions appearing in object file compiled with aCC
(attachment 47829). I took a look at it a bit more last night and realized that
the code that was causing relocation issues with gcc was not compiled in when
using aCC. After a bit of mucking around with aCC to approximate compilations
options to as close as possible to gcc ones (so -O0, no inlining, target arhc,
etc...) and enabling gnu mode and a few defines allowed me to compile the
relevant parts in to the object. You can see the .o and .s from aCC as well as
a few more dumps in attachment 47840.
Just to make sure I do not waste your time, I tried to get some info for you
from the gcc dumps (attachment 47828) as you have previously requested for
sancov.c (please let me know if I made any mistakes there).
Original linker error was:
--------------------
ld: The value 0xfffffffffdf81640 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file
libbackend.a[gimple-expr.o]
--------------------
Looking for section 59's name and confirming with readlef:
--------------------
$ elfdump -C -D 59 -h gimple-expr.o
gimple-expr.o:
*** Section Header ***
Idx: 59
Section: .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
Type: PBIT Flags: ------ EA-
Vaddr: 0x00000000 Offset: 0x0000cd50
Size: 0x00000240 Link: 00000000
Info: 00000000 Align: 0x00000010
Entsize: 0x00000000
$ readelf -S -W gimple-expr.o | grep '\[59\]'
[59] .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ PROGBITS
00000000 00cd50 000240 00 AX 0 0 16
--------------------
Dumping relocations for this section:
--------------------
$ objdump -r -j .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
gimple-expr.o
gimple-expr.o: file format elf32-ia64-hpux-big
RELOCATION RECORDS FOR
[.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_]:
OFFSET TYPE VALUE
00000071 LTOFF22X .rodata
00000080 LDXMOV .rodata
00000082 LTOFF22X .rodata+0x00000188
00000090 LDXMOV .rodata+0x00000188
00000092 PCREL21B _Z10expr_checkPK9tree_nodePKciS3_
00000102 PCREL21B .text
000001d2 PCREL21B _Z25tree_operand_check_failediPK9tree_nodePKciS3_
--------------------
And we can see the PCREL21B relocation at offset 0x102 there.
And here is a disassembly of this section showing the same PCREL21B relocation
at the same offset. If I understand the code correctly than that should be a
call to tree_operand_length() at that offset.
--------------------
$ objdump -d -C -S -t -r -j
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ gimple-expr.o
gimple-expr.o: file format elf32-ia64-hpux-big
SYMBOL TABLE:
00000000 l d .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
00000000 .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
00000000 w F .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
00000240 tree_operand_check(tree_node const*, int, char const*, int, char
const*)
Disassembly of section
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_:
00000000 <tree_operand_check(tree_node const*, int, char const*, int, char
const*)>:
}
inline const_tree *
tree_operand_check (const_tree __t, int __i,
const char *__f, int __l, const char *__g)
{
0: 00 30 39 12 80 05 [MII] alloc r38=ar.pfs,14,9,0
6: 70 02 30 00 42 80 mov r39=r12
c: 01 65 fc 8c adds r12=-48,r12
10: 01 00 00 00 01 00 [MII] nop.m 0x0
16: 50 02 00 62 00 00 mov r37=b0
1c: 05 08 00 84 mov r40=r1;;
20: 0b 70 c0 4f 3f 23 [MMI] adds r14=-16,r39;;
26: 00 00 39 20 23 c0 st4 [r14]=r32
2c: 41 3f fd 8c adds r14=-12,r39;;
30: 02 00 84 1c 90 11 [MII] st4 [r14]=r33
36: e0 c0 9f 7e 46 00 adds r14=-8,r39;;
3c: 00 00 04 00 nop.i 0x0
40: 02 00 88 1c 90 11 [MII] st4 [r14]=r34
46: e0 e0 9f 7e 46 00 adds r14=-4,r39;;
4c: 00 00 04 00 nop.i 0x0
50: 02 00 8c 1c 90 11 [MII] st4 [r14]=r35
56: e0 00 9c 00 42 00 mov r14=r39;;
5c: 00 00 04 00 nop.i 0x0
60: 02 00 90 1c 90 11 [MII] st4 [r14]=r36
const_tree __u = EXPR_CHECK (__t);
66: e0 80 9f 7e 46 00 adds r14=-16,r39;;
6c: 00 00 04 00 nop.i 0x0
70: 02 48 01 1c 10 10 [MII] ld4 r41=[r14]
71: LTOFF22X .rodata
76: a0 02 04 00 48 00 addl r42=0,r1;;
7c: 00 00 04 00 nop.i 0x0
80: 01 50 01 54 18 10 [MII] ld8 r42=[r42]
80: LDXMOV .rodata
82: LTOFF22X .rodata+0x188
86: b0 52 03 30 48 80 mov r43=3178
8c: 05 08 00 90 addl r44=0,r1;;
90: 10 60 01 58 18 10 [MIB] ld8 r44=[r44]
90: LDXMOV .rodata+0x188
92: PCREL21B expr_check(tree_node const*, char
const*, int, char const*)
96: 00 00 00 02 00 00 nop.i 0x0
9c: 08 00 00 50 br.call.sptk.many b0=90
<tree_operand_check(tree_node const*, int, char const*, int, char const*)+0x90>
a0: 02 08 00 50 00 21 [MII] mov r1=r40
a6: e0 00 9f 7e 46 00 adds r14=-32,r39;;
ac: 00 00 04 00 nop.i 0x0
b0: 02 00 20 1c 90 11 [MII] st4 [r14]=r8
if (__i < 0 || __i >= TREE_OPERAND_LENGTH (__u))
b6: e0 a0 9f 7e 46 00 adds r14=-12,r39;;
bc: 00 00 04 00 nop.i 0x0
c0: 0b 70 00 1c 10 10 [MMI] ld4 r14=[r14];;
c6: 60 70 00 0e 61 00 cmp4.lt p6,p7=r14,r0
cc: 00 00 04 00 nop.i 0x0;;
d0: cb 70 04 00 00 e1 [MMI] (p06) adds r14=1,r0;;
d6: e1 00 00 00 42 00 (p07) mov r14=r0
dc: 00 00 04 00 nop.i 0x0;;
e0: 10 00 00 00 01 00 [MIB] nop.m 0x0
e6: 70 00 38 0c 28 03 tbit.z p7,p6=r14,0
ec: 70 00 00 42 (p06) br.cond.dptk.few 150
<tree_operand_check(tree_node const*, int, char const*, int, char
const*)+0x150>
f0: 0a 70 80 4f 3f 23 [MMI] adds r14=-32,r39;;
f6: 90 02 38 20 20 00 ld4 r41=[r14]
fc: 00 00 04 00 nop.i 0x0
100: 10 00 00 00 01 00 [MIB] nop.m 0x0
102: PCREL21B .text
106: 00 00 00 02 00 00 nop.i 0x0
10c: 08 00 00 50 br.call.sptk.many b0=100
<tree_operand_check(tree_node const*, int, char const*, int, char
const*)+0x100>
110: 01 08 00 50 00 21 [MII] mov r1=r40
116: f0 00 20 00 42 c0 mov r15=r8
11c: 41 3f fd 8c adds r14=-12,r39;;
120: 0b 70 00 1c 10 10 [MMI] ld4 r14=[r14];;
126: 60 70 3c 0e 61 00 cmp4.lt p6,p7=r14,r15
12c: 00 00 04 00 nop.i 0x0;;
130: cb 70 04 00 00 e1 [MMI] (p06) adds r14=1,r0;;
136: e1 00 00 00 42 00 (p07) mov r14=r0
13c: 00 00 04 00 nop.i 0x0;;
140: 10 00 00 00 01 00 [MIB] nop.m 0x0
146: 70 00 38 0c 28 03 tbit.z p7,p6=r14,0
14c: 20 00 00 42 (p06) br.cond.dptk.few 160
<tree_operand_check(tree_node const*, int, char const*, int, char
const*)+0x160>
150: 11 70 04 00 00 24 [MIB] mov r14=1
156: 00 00 00 02 00 00 nop.i 0x0
15c: 20 00 00 40 br.few 170
<tree_operand_check(tree_node const*, int, char const*, int, char
const*)+0x170>;;
160: 01 70 00 00 00 21 [MII] mov r14=r0
166: 00 00 00 02 00 00 nop.i 0x0
16c: 00 00 04 00 nop.i 0x0;;
170: 0b 30 00 1c 87 b9 [MMI] cmp4.eq p6,p7=0,r14;;
176: e1 08 00 00 42 00 (p06) adds r14=1,r0
17c: 00 00 04 00 nop.i 0x0;;
180: ea 70 00 00 00 21 [MMI] (p07) mov r14=r0;;
186: 00 00 00 02 00 e0 nop.m 0x0
18c: 00 70 18 50 tbit.z p7,p6=r14,0
190: 10 00 00 00 01 00 [MIB] nop.m 0x0
196: 00 00 00 02 00 03 nop.i 0x0
19c: 50 00 00 42 (p06) br.cond.dptk.few 1e0
<tree_operand_check(tree_node const*, int, char const*, int, char
const*)+0x1e0>
tree_operand_check_failed (__i, __u, __f, __l, __g);
1a0: 00 88 d0 4f 3f 23 [MII] adds r17=-12,r39
1a6: 00 c1 9f 7e 46 e0 adds r16=-8,r39
1ac: c1 3f fd 8c adds r15=-4,r39
1b0: 0b 70 00 4e 00 21 [MMI] mov r14=r39;;
1b6: 90 02 44 20 20 20 ld4 r41=[r17]
1bc: 02 3e fd 8c adds r17=-32,r39;;
1c0: 08 50 01 22 10 10 [MMI] ld4 r42=[r17]
1c6: b0 02 40 20 20 00 ld4 r43=[r16]
1cc: 00 00 04 00 nop.i 0x0
1d0: 19 60 01 1e 10 10 [MMB] ld4 r44=[r15]
1d2: PCREL21B tree_operand_check_failed(int,
tree_node const*, char const*, int, char const*)
1d6: d0 02 38 20 20 00 ld4 r45=[r14]
1dc: 08 00 00 50 br.call.sptk.many b0=1d0
<tree_operand_check(tree_node const*, int, char const*, int, char
const*)+0x1d0>;;
return CONST_CAST (const_tree *, &__u->exp.operands[__i]);
1e0: 0b 70 d0 4f 3f 23 [MMI] adds r14=-12,r39;;
1e6: e0 00 38 20 20 00 ld4 r14=[r14]
1ec: 00 00 04 00 nop.i 0x0;;
1f0: 0b 70 10 1c 00 21 [MMI] adds r14=4,r14;;
1f6: e0 70 00 22 40 00 shladd r14=r14,2,r0
1fc: 02 3e fd 8c adds r16=-32,r39;;
200: 0b 78 00 20 10 10 [MMI] ld4 r15=[r16];;
206: e0 78 38 00 40 00 add r14=r15,r14
20c: 00 00 04 00 nop.i 0x0;;
210: 0a 70 00 1c 80 21 [MMI] addp4 r14=0,r14;;
}
216: 80 00 38 00 42 00 mov r8=r14
21c: 60 02 aa 00 mov.i ar.pfs=r38
220: 00 00 00 00 01 00 [MII] nop.m 0x0
226: 00 28 05 80 03 80 mov b0=r37
22c: 01 38 01 84 mov r12=r39
230: 11 00 00 00 01 00 [MIB] nop.m 0x0
236: 00 00 00 02 00 80 nop.i 0x0
23c: 08 00 84 00 br.ret.sptk.many b0;;
--------------------
If I try to compare this to aCC dump in attachment 47840, I do not see any
calls to weak. Equivalent section to the above dump in gimple-expr.s
(_Z18tree_operand_checkPK9tree_nodeiPKciS3_) can be found on line 9007, also
gimple-expr.o.objdump on line 2099. I believe the place where with gcc we
expect to see a call to tree_operand_length() through PCREL21B reloc, aCC does
similar thing in gimple-expr.s line 9098 (gimple-expr.o.objdump line 2181).
Please let me know if I am on the right track here or missing something.
Is any of this helpful for now?
Thanks!
--peter
More information about the Gcc-bugs
mailing list