|
From: Julian S. <js...@ac...> - 2005-10-21 01:51:02
|
V is declining to read debug info from various .so's on various PPC distros. It complains, when reading the section headers, that one of the sections it's looking for (.plt, in this example) has an offset+size value which extends beyond the end of the file. And it's correct to do so: sewardj@minnie:~$ readelf -S /usr/lib/qt-3.3/plugins/styles/wonderland.so There are 28 section headers, starting at offset 0x156e4: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [...] [24] .plt NOBITS 00025618 0155f0 000918 00 WAX 0 0 4 Offset(0x0155f0) + Size(0x000918) = 0x15f08 = 89864, whilst the file size is only 88900. Also it's a bit strange that there are a four of sections that start at the same offset: [23] .sbss NOBITS 000255f0 0155f0 000028 00 WA 0 0 8 [24] .plt NOBITS 00025618 0155f0 000918 00 WAX 0 0 4 [25] .bss NOBITS 00025f30 0155f0 000000 00 WA 0 0 1 [26] .gnu_debuglink PROGBITS 00000000 0155f0 000018 00 0 0 4 Any ideas? This only happens for 1-in-10-ish .so's (very approximately). For the rest the debuginfo reader works fine. At first I thought it might be an endianness thing, but the fact that V's numbers agree with readelf's dissuaded me of that. J |
|
From: Greg P. <gp...@us...> - 2005-10-21 02:09:18
|
Julian Seward writes: > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [...] > [24] .plt NOBITS 00025618 0155f0 000918 00 WAX 0 0 4 > > Offset(0x0155f0) + Size(0x000918) = 0x15f08 = 89864, whilst the file > size is only 88900. Note the NOBITS section type. A NOBITS section creates zero-filled memory when loaded. It doesn't occupy any space in the file. > Also it's a bit strange that there are a four of sections that start > at the same offset: > > [23] .sbss NOBITS 000255f0 0155f0 000028 00 WA 0 0 8 > [24] .plt NOBITS 00025618 0155f0 000918 00 WAX 0 0 4 > [25] .bss NOBITS 00025f30 0155f0 000000 00 WA 0 0 1 > [26] .gnu_debuglink PROGBITS 00000000 0155f0 000018 00 0 0 4 Three of these are also NOBITS sections. They don't occupy any space in the file so they don't overlap with the following PROGBITS section. Their file offsets are ignored. -- Greg Parker gp...@us... |
> Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [...] > [24] .plt NOBITS 00025618 0155f0 000918 00 WAX 0 0 4 > > Offset(0x0155f0) + Size(0x000918) = 0x15f08 = 89864, whilst the file > size is only 88900. In a .so, Segment placement (ElfXX_Phdr.p_type==PT_LOAD) is performed first (including ".bss expansion" when .p_filesz < .p_memsz) before Section interpretation. > Also it's a bit strange that there are a four of sections that start > at the same offset: > > [23] .sbss NOBITS 000255f0 0155f0 000028 00 WA 0 0 8 > [24] .plt NOBITS 00025618 0155f0 000918 00 WAX 0 0 4 > [25] .bss NOBITS 00025f30 0155f0 000000 00 WA 0 0 1 > [26] .gnu_debuglink PROGBITS 00000000 0155f0 000018 00 0 0 4 > > Any ideas? In the list above, .sbss .plt .bss are all NOBITS, are beyond .p_filesz and within .p_memsz, and have no content that needs to appear literally in the .so because their content is all bytes are zero. This saves space in the filesystem, and I/O time at runtime, at the cost of complexity. -- |
|
From: Julian S. <js...@ac...> - 2005-10-21 05:10:22
|
> [23] .sbss NOBITS 000255f0 0155f0 000028 00 WA 0 0 8 > [24] .plt NOBITS 00025618 0155f0 000918 00 WAX 0 0 4 > [25] .bss NOBITS 00025f30 0155f0 000000 00 WA 0 0 1 > [26] .gnu_debuglink PROGBITS 00000000 0155f0 000018 00 0 0 4 On reading the ELF docs, this might be because the .plt is marked NOBITS, which means the section really has zero size in the file. This is different from x86 and amd64, which mark it as PROGBITS. J |