RFH/RFC: ld generating incorrect Elf DT

Discussion:

RFH/RFC: ld generating incorrect Elf DT_RELSZ...

David Daney

2005-05-20 20:37:23 UTC

I am running a binutils-2.16 / gcc-4.0.0 cross toolchain with
--target=mipsel-linux --host=i686-pc-linux-gnu.

It looks to me like ld is generating DT_RELSZ with the wrong value (too
small). This causes ld.so to not fully relocate the object resulting in
runtime errors.

The object in question is libgcj.so.6.0.0 which is the java runtime
library from gcc-4.0.0.

Here is the information which shows the problem:

$ mipsel-linux-readelf -d libgcj.so.6

Dynamic section at offset 0xec contains 30 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000e (SONAME) Library soname: [libgcj.so.6]
0x0000000c (INIT) 0x5f1620
0x0000000d (FINI) 0xb30830
0x00000004 (HASH) 0x204
0x00000005 (STRTAB) 0xe8c18
0x00000006 (SYMTAB) 0x48418
0x0000000a (STRSZ) 2301918 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000016 (TEXTREL) 0x0
0x00000003 (PLTGOT) 0x102f640
0x00000011 (REL) 0x32ee08
0x00000012 (RELSZ) 2661784 (bytes)
0x00000013 (RELENT) 8 (bytes)
.
.
.

From this I calculate that ld.so will do 2661784/8 == 332723
(RELSZ/RELENT) relocations.

$ mipsel-linux-readelf -W -r libgcj.so.6 | more

Relocation section '.rel.dyn' at offset 0x32ee08 contains 361731 entries:
Offset Info Type Sym. Value Symbol's Name
00000000 00000000 R_MIPS_NONE
.
.
.

.rel.dyn contains 361731 relocations.

In theory all relocations that come after RELSZ/RELENT should be
R_MIPS_NONE as they presumable would not be needed. This should be
361731 - 332723 == 29008 unneeded relocation slots in the end of .rel.dyn.

However if I do:
[***@dl2 .libs]$ mipsel-linux-readelf -W -r libgcj.so.6 | tail -n
29008 | more
0105414c 00a06903 R_MIPS_REL32 00fc0bc0
_ZN5javax8security4sasl13SaslException6class$E
01056428 00a06a03 R_MIPS_REL32 0099fd24
_ZN5javax5swing4text28DefaultEditorKit$PasteActionC1Ev
00dfe64c 00a06b03 R_MIPS_REL32 00fe6a50
_ZN3gnu3xml9transform15CurrentFunction6class$E
01052808 00a06b03 R_MIPS_REL32 00fe6a50
_ZN3gnu3xml9transform15CurrentFunction6class$E
00fbf600 00a06c03 R_MIPS_REL32 00fbf518
_ZN5javax8security4auth8callback20ConfirmationCallback16OK_CANCEL_OPTIONE
01053030 00a06c03 R_MIPS_REL32 00fbf518
_ZN5javax8security4auth8callback20ConfirmationCallback16OK_CANCEL_OPTIONE
00dfde6c 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fa4abc 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fa4fcc 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fa677c 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fa693c 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00faa6dc 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fac0a8 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fac2f8 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fac688 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fae0e8 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
00fae378 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
01064b74 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
01054128 00a06d03 R_MIPS_REL32 00fa4060
_ZN5javax5print9attribute9Attribute6class$E
0105e5b8 00a06e03 R_MIPS_REL32 00979100
_ZN5javax5swing11JOptionPane12getRootFrameEv
00ef0b18 00a06f03 R_MIPS_REL32 00eeff34
_ZN4java3awt5event8KeyEvent7VK_LESSE
0105b9c4 00a06f03 R_MIPS_REL32 00eeff34
_ZN4java3awt5event8KeyEvent7VK_LESSE
00fa17e4 00a07003 R_MIPS_REL32 00fa184c
_ZTVN5javax3net3ssl13SSLPermissionE
01064b24 00a07003 R_MIPS_REL32 00fa184c
_ZTVN5javax3net3ssl13SSLPermissionE
00f6361c 00a07103 R_MIPS_REL32 00983be8
_ZN5javax5swing11JTabbedPane20getAccessibleContextEv
0106221c 00a07103 R_MIPS_REL32 00983be8
_ZN5javax5swing11JTabbedPane20getAccessibleContextEv
00f628e8 00a07203 R_MIPS_REL32 00980680
_ZN5javax5swing8JSpinner8getModelEv
0105d0a8 00a07203 R_MIPS_REL32 00980680
_ZN5javax5swing8JSpinner8getModelEv
00f525d0 00a07303 R_MIPS_REL32 0096a988
_ZN5javax5swing16DefaultListModel12getElementAtEi
0105eac8 00a07303 R_MIPS_REL32 0096a988
_ZN5javax5swing16DefaultListModel12getElementAtEi
00f1ba98 00a07403 R_MIPS_REL32 008f1d1c
_ZN4java5beans11beancontext26BeanContextServicesSupport24getCurrentServiceClassesEv
0105dfb4 00a07403 R_MIPS_REL32 008f1d1c
_ZN4java5beans11beancontext26BeanContextServicesSupport24getCurrentServiceClassesEv
00efdff4 00a07503 R_MIPS_REL32 00efdd7c
_ZN4java3awt5image13BufferedImage16TYPE_BYTE_BINARYE
01058be0 00a07503 R_MIPS_REL32 00efdd7c
_ZN4java3awt5image13BufferedImage16TYPE_BYTE_BINARYE
00eeb52c 00a07603 R_MIPS_REL32 00eeb1a0
_ZN4java3awt5color11ICC_Profile14icSigSpaceDCLRE
0105bab8 00a07603 R_MIPS_REL32 00eeb1a0
_ZN4java3awt5color11ICC_Profile14icSigSpaceDCLRE
00edc3e8 00a07703 R_MIPS_REL32 0084cb1c
_ZN4java3awt10EventQueue4pushEPS1_
01056ce4 00a07703 R_MIPS_REL32 0084cb1c
_ZN4java3awt10EventQueue4pushEPS1_
00ed3938 00a07803 R_MIPS_REL32 00833c10
_ZN4java3awt26Button$AccessibleAWTButton17getAccessibleRoleEv
01064c54 00a07803 R_MIPS_REL32 00833c10
_ZN4java3awt26Button$AccessibleAWTButton17getAccessibleRoleEv
00f225e4 00a07903 R_MIPS_REL32 00f22668
_ZTVN5javax5swing39AbstractButton$AccessibleAbstractButtonE
0105b1d0 00a07903 R_MIPS_REL32 00f22668
_ZTVN5javax5swing39AbstractButton$AccessibleAbstractButtonE
00ed3e48 00a07a03 R_MIPS_REL32 00834608
_ZN4java3awt6Button20getAccessibleContextEv
0105e31c 00a07a03 R_MIPS_REL32 00834608
_ZN4java3awt6Button20getAccessibleContextEv
00f67998 00a07b03 R_MIPS_REL32 00986f2c
_ZN5javax5swing5JTree34getPreferredScrollableViewportSizeEv
0105ef30 00a07b03 R_MIPS_REL32 00986f2c
_ZN5javax5swing5JTree34getPreferredScrollableViewportSizeEv
00f2a928 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
00f2aaf8 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
00f324c8 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
00f3bf18 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
00f3c0e8 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
00f3c2e8 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
00f3cbb4 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
01061ad0 00a07c03 R_MIPS_REL32 009428b8
_ZN5javax5swing4plaf5basic11BasicTextUI25getNextVisualPositionFromEPNS0_4text14JTextComponentEiPNS4_13Position$BiasEiP6JArrayIS8_E
00eec324 00a07d03 R_MIPS_REL32 00eec38c
_ZTVN4java3awt5color12CMMExceptionE
010634ec 00a07d03 R_MIPS_REL32 00eec38c
_ZTVN4java3awt5color12CMMExceptionE
00ed9bd8 00a07e03 R_MIPS_REL32 00845a20
_ZN4java3awt25Container$GfxPaintVisitor5visitEPNS0_9ComponentEPNS0_8GraphicsE
0106480c 00a07e03 R_MIPS_REL32 00845a20
_ZN4java3awt25Container$GfxPaintVisitor5visitEPNS0_9ComponentEPNS0_8GraphicsE
00fc3448 00a07f03 R_MIPS_REL32 01076188
_ZN5javax13accessibility15AccessibleState9COLLAPSEDE
01053fa4 00a07f03 R_MIPS_REL32 01076188
_ZN5javax13accessibility15AccessibleState9COLLAPSEDE
00000000 00000000 R_MIPS_NONE
00000000 00000000 R_MIPS_NONE
00000000 00000000 R_MIPS_NONE
00000000 00000000 R_MIPS_NONE
.
.
.

You can see that there are quite a few needed relocations that will not
be done.

Any Ideas about what is going on here?

Thanks in advance for any insight.

David Daney.

Daniel Jacobowitz

2005-05-20 20:44:01 UTC

Permalink

Post by David Daney
I am running a binutils-2.16 / gcc-4.0.0 cross toolchain with
--target=mipsel-linux --host=i686-pc-linux-gnu.
It looks to me like ld is generating DT_RELSZ with the wrong value (too
small). This causes ld.so to not fully relocate the object resulting in
runtime errors.
The object in question is libgcj.so.6.0.0 which is the java runtime
library from gcc-4.0.0.

It sounds like we've botched the offsets somehow.

Post by David Daney
From this I calculate that ld.so will do 2661784/8 == 332723
(RELSZ/RELENT) relocations.
$ mipsel-linux-readelf -W -r libgcj.so.6 | more
Offset Info Type Sym. Value Symbol's Name
00000000 00000000 R_MIPS_NONE
.
.
.
.rel.dyn contains 361731 relocations.

The size of .rel.dyn is rarely all that relevant. That it starts with
R_MIPS_NONE is very odd, though.

Does this match what you get from readelf -Dr, which will use the
dynamic tags to locate the relocations?

Post by David Daney
You can see that there are quite a few needed relocations that will not
be done.

But not on the order of 29,000, right? Just the hundred or so that you
pasted?

--
Daniel Jacobowitz
CodeSourcery, LLC

David Daney

2005-05-20 20:56:43 UTC

Permalink

Thanks Daniel,

Post by Daniel Jacobowitz

It sounds like we've botched the offsets somehow.

The size of .rel.dyn is rarely all that relevant. That it starts with
R_MIPS_NONE is very odd, though.

It always (on all objects I have examined) seems to start with exactly
one R_MIPS_NONE then valid relocations follow.

Post by Daniel Jacobowitz

Does this match what you get from readelf -Dr, which will use the
dynamic tags to locate the relocations?

readelf -Dr reports exactly DT_RELSZ bytes. But that is the problem.
DT_RELSZ is incorrect.

Post by Daniel Jacobowitz

Post by David Daney
You can see that there are quite a few needed relocations that will not
be done.

But not on the order of 29,000, right? Just the hundred or so that you
pasted?

Correct.

It should be noted that my libgcj.so.5 (from gcc-3.4.3) does not suffer
from this problem, but it is quite a bit smaller ( RELSZ= 609600 instead
of 2661784). Also libgcj.so.? from gcc-4.1 is similarly broken.

David Daney.

Daniel Jacobowitz

2005-05-20 21:43:10 UTC

Permalink

The single R_MIPS_NONE is OK. I'd forgotten about that. I think it's
for IRIX compat.

Post by David Daney

Post by Daniel Jacobowitz
But not on the order of 29,000, right? Just the hundred or so that you
pasted?

Correct.
It should be noted that my libgcj.so.5 (from gcc-3.4.3) does not suffer
from this problem, but it is quite a bit smaller ( RELSZ= 609600 instead
of 2661784). Also libgcj.so.? from gcc-4.1 is similarly broken.

You get to debug the offsets, then. Someone must have messed up
reloc_count, or else another section is getting merged into the output
.rel.dyn section.

Try with conditional watchpoints on an x86 host. reloc_count goes up
as we allocate the section, down to 0, then up as we output
relocations. I see no way we could be outputting relocations without
incrementing it though.

--
Daniel Jacobowitz
CodeSourcery, LLC

David Daney

2005-05-20 22:35:20 UTC

Permalink

Post by Daniel Jacobowitz
The single R_MIPS_NONE is OK. I'd forgotten about that. I think it's
for IRIX compat.

Post by David Daney

Post by Daniel Jacobowitz
But not on the order of 29,000, right? Just the hundred or so that you
pasted?

Correct.
It should be noted that my libgcj.so.5 (from gcc-3.4.3) does not suffer
from this problem, but it is quite a bit smaller ( RELSZ= 609600 instead
of 2661784). Also libgcj.so.? from gcc-4.1 is similarly broken.

You get to debug the offsets, then. Someone must have messed up
reloc_count, or else another section is getting merged into the output
.rel.dyn section.
Try with conditional watchpoints on an x86 host. reloc_count goes up
as we allocate the section, down to 0, then up as we output
relocations. I see no way we could be outputting relocations without
incrementing it though.

Just to save me a little time, could you tell me which files or
functions (presumably in bfd) do this?

David Daney

Daniel Jacobowitz

2005-05-21 02:34:33 UTC

Permalink

Post by David Daney
Just to save me a little time, could you tell me which files or
functions (presumably in bfd) do this?

Everything should be in elfxx-mips.c. You can find easily where it
sets DT_RELSZ; that's late in the process. Then see how we count up
that variable.

--
Daniel Jacobowitz
CodeSourcery, LLC

David Daney

2005-05-23 19:59:49 UTC

Permalink

Post by Daniel Jacobowitz

Post by David Daney
Just to save me a little time, could you tell me which files or
functions (presumably in bfd) do this?

Everything should be in elfxx-mips.c. You can find easily where it
sets DT_RELSZ; that's late in the process. Then see how we count up
that variable.

Thanks,

The problem is that dynamic relocations for the non-primary gots are
being added after DT_RELSZ is calculated.

I am working on a patch.

David Daney.

Richard Sandiford

2005-05-21 11:05:03 UTC

Permalink

Post by David Daney
In theory all relocations that come after RELSZ/RELENT should be
R_MIPS_NONE as they presumable would not be needed. This should be
361731 - 332723 == 29008 unneeded relocation slots in the end of .rel.dyn.
29008 | more
0105414c 00a06903 R_MIPS_REL32 00fc0bc0
_ZN5javax8security4sasl13SaslException6class$E
01056428 00a06a03 R_MIPS_REL32 0099fd24
_ZN5javax5swing4text28DefaultEditorKit$PasteActionC1Ev
00dfe64c 00a06b03 R_MIPS_REL32 00fe6a50
_ZN3gnu3xml9transform15CurrentFunction6class$E
[...]
You can see that there are quite a few needed relocations that will not
be done.

Are there any other R_MIPS_NONE relocations before the cut-off point?
(Besides the first one, I mean.) It sounded from your message like you
might have checked, and that (as expected) there weren't, but I just
wanted to make sure.

Richard

David Daney

2005-05-23 20:01:38 UTC

Permalink

Post by Richard Sandiford

There are none. The relocations are sorted so they all end up at the
end. As I said in the other message: The problem is that dynamic
relocations for the non-primary gots are being added after DT_RELSZ is
calculated.

I am working on a patch.

David Daney