This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS/gas bug
On Thu, Nov 06, 2003 at 07:42:50PM -0800, david daney wrote:
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> >>On Thu, Nov 06, 2003 at 05:30:41PM -0800, David Daney wrote:
> >> The attached ptrflags.s file causes gas to generate incorrect object
> >> files. It was generated by a recient gcc3.4 snapshop from ptrflags.C in
> >> the g++ testsuite.
> >>
> >> The failure is in H.J Lu's 2.14.90.0.5 20030722 as well as the 031106
> >> snapshot that I just built.
> >>
> >> Both are configured like this:
> >>
> >> ../binutils-031106/configure --host=i686-pc-linux-gnu
> >> --target=mipsisa32el-linux --prefix=/home/mipsel-linux
> >> '--libdir=${exec_prefix}/mipsel-linux/i386-linux/lib'
> >>
> >> The gas command line that creates the bad output is:
> >>
> >> mipsel-butest/gas/as-new -EL -32 -v -KPIC -o ptrflags.o ptrflags.s
> >>
> >> $ mipsel-linux-readelf -r ptrflags.o
> >>
> >> Relocation section '.rel.text' at offset 0x167c contains 35 entries:
> >> Offset Info Type Sym.Value Sym. Name
> >> 00000000 00002b05 R_MIPS_HI16 00000000 _gp_disp
> >> 00000004 00002b06 R_MIPS_LO16 00000000 _gp_disp
> >> 00000040 00002c0b R_MIPS_CALL16 00000000 __dynamic_cast
> >> 00000048 00002d09 R_MIPS_GOT16 00000000 _ZTISt9type_info
> >> 0000004c 00002e09 R_MIPS_GOT16 00000000 _ZTIN10__cxxabiv117__p
> >> 000000c8 00002b05 R_MIPS_HI16 00000000 _gp_disp
> >> 000000cc 00002b06 R_MIPS_LO16 00000000 _gp_disp
> >> 000000ec 00003009 R_MIPS_GOT16 00000000 _ZTIP1A
> >> 000000f0 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000011c 00003109 R_MIPS_GOT16 00000000 _ZTIPK1A
> >> 00000120 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000014c 00003209 R_MIPS_GOT16 00000000 _ZTIPV1A
> >> 00000150 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000017c 00003309 R_MIPS_GOT16 00000000 _ZTIPrP1A
> >> 00000180 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 000001ac 00003409 R_MIPS_GOT16 00000000 _ZTIM1Ai
> >> 000001b0 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 000001dc 00003509 R_MIPS_GOT16 00000000 _ZTIPM1Ai
> >> 000001e0 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000020c 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 00000210 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000023c 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 00000240 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000026c 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 00000270 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000029c 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 000002a0 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 000002cc 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 000002d0 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 000002fc 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 00000300 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000032c 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 00000330 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> 0000035c 00001409 R_MIPS_GOT16 00000000 .data.rel.ro
> >> 00000360 00002a0b R_MIPS_CALL16 00000000 _Z6expectiRKSt9type_in
> >> .
> >> .
> >> .
> >>
> >> The symptom is all of the "R_MIPS_GOT16 00000000 .data.rel.ro"
> >> relocations. They should all be something similar to _ZTIM1Ai
> >> _ZTIPM1Ai, etc
> >>
> >> Has anybody seen this before?
> >>
> >> What is the solution?
> >
> >Could you explain why it is a problem with the assembler? Here's the
> >difference I think:
>
> It is a problem because the linker dies when it gets to the relocation at 20C.
>
> I assumed it was a problem with the assembler, because I have seen other genuine screw-ups of this nature from the assembler.
>
> If it is not the assembler, then the only other possibilities are ld or G++.
>
> Where do you think the problem is?
I don't know, I was just responding to what you gave us. Dies how? I
can see that a GOT16 relocation against a section might cause problems
somehow. Can you construct a smaller testcase?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer