New build, gobjcopy failure, any clues?
David Chase
david.r.chase at oracle.com
Tue Mar 26 19:12:24 UTC 2013
gobjdump -x fails in the same uninformative way.
elfdump -e libjvm.so
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_DYN
e_flags: [ EF_SPARCV9_TSO ]
e_entry: 0 e_ehsize: 64 e_shstrndx: 34
e_shoff: 0x27ce2658 e_shentsize: 64 e_shnum: 37
e_phoff: 0x40 e_phentsize: 56 e_phnum: 3
Very similar to yours, though different numbers.
I wonder if e_entry=0 means anything.
Other elfdump flags (-c, -d) provide similar reasonable-looking output.
David
On 2013-03-26, at 2:57 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> Can you try if 'gobjdump -x' doesn't work as well?
> And you can also try '/usr/ccs/bin/elfdump -e'.
>
> For me '/usr/ccs/bin/elfdump -e' gives:
>
> ELF Header
> ei_magic: { 0x7f, E, L, F }
> ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
> e_machine: EM_SPARCV9 e_version: EV_CURRENT
> e_type: ET_DYN
> e_flags: [ EF_SPARCV9_TSO ]
> e_entry: 0xe8 e_ehsize: 64 e_shstrndx: 27
> e_shoff: 0x2478b68 e_shentsize: 64 e_shnum: 29
> e_phoff: 0x40 e_phentsize: 56 e_phnum: 3
>
>
> And 'gobjdump -x' prints:
>
> /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u-fastdebug/lib/sparcv9/server/libjvm.so:
> file format elf64-sparc
> /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u-fastdebug/lib/sparcv9/server/libjvm.so
> architecture: sparc:v9, flags 0x00000150:
> HAS_SYMS, DYNAMIC, D_PAGED
> start address 0x00000000000000e8
>
> Program Header:
> LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr
> 0x0000000000000000 align 2**20
> filesz 0x0000000001afe0bf memsz 0x0000000001afe0bf flags r-x
> LOAD off 0x0000000001afe0c0 vaddr 0x0000000001bfe0c0 paddr
> 0x0000000000000000 align 2**20
> filesz 0x0000000000140c74 memsz 0x00000000001b8520 flags rwx
> DYNAMIC off 0x0000000001b05128 vaddr 0x0000000001c05128 paddr
> 0x0000000000000000 align 2**0
> filesz 0x0000000000000210 memsz 0x0000000000000000 flags rwx
>
> Dynamic Section:
> NEEDED libsocket.so.1
> NEEDED libsched.so.1
> NEEDED libdl.so.1
> NEEDED libm.so.1
> NEEDED libCrun.so.1
> NEEDED libthread.so.1
> NEEDED libdoor.so.1
> NEEDED libc.so.1
> NEEDED libdemangle.so.1
> NEEDED libkstat.so.1
> INIT 0x139bb88
> FINI 0x139be88
> SONAME libjvm.so
> HASH 0xe8
> STRTAB 0x19718
> STRSZ 0x17071
> SYMTAB 0x6680
> SYMENT 0x18
> CHECKSUM 0x53fa
> PLTRELSZ 0x14b8
> PLTREL 0x7
> JMPREL 0x22def0
> RELA 0x30790
> RELASZ 0x1fec18
> RELAENT 0x18
> 0x70000001 0x8d4
> 0x70000001 0x8e5
> 0x70000001 0x811
> FEATURE 0x1
> FLAGS 0x0
> FLAGS_1 0x0
> PLTGOT 0x1c03500
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .hash 00006598 00000000000000e8 00000000000000e8 000000e8 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 1 .dynsym 00013098 0000000000006680 0000000000006680 00006680 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 2 .dynstr 00017071 0000000000019718 0000000000019718 00019718 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 .rela.got 0000fb40 0000000000030790 0000000000030790 00030790 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .rela.ex_shared 000000c0 00000000000402d0 00000000000402d0 000402d0 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .rela.cpp_finidata 00000048 0000000000040390 0000000000040390
> 00040390 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .rela.data 001edb18 00000000000403d8 00000000000403d8 000403d8 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .rela.plt 000014b8 000000000022def0 000000000022def0 0022def0 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 8 .text 0116c7c4 000000000022f3c0 000000000022f3c0 0022f3c0 2**5
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 9 .init 00000300 000000000139bb88 000000000139bb88 0139bb88 2**3
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 10 .fini 00000094 000000000139be88 000000000139be88 0139be88 2**3
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 11 .exception_ranges 00000008 000000000139bf20 000000000139bf20
> 0139bf20 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 12 .rodata 00703d55 000000000139bf28 000000000139bf28 0139bf28 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 13 .rodata1 0003b3b3 0000000001a9fc7d 0000000001a9fc7d 01a9fc7d 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 14 .got 000053c8 0000000001bfe0c0 0000000001bfe0c0 01afe0c0 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 15 .plt 00001c24 0000000001c03500 0000000001c03500 01b03500 2**8
> CONTENTS, ALLOC, LOAD, CODE
> 16 .dynamic 00000210 0000000001c05128 0000000001c05128 01b05128 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 17 .ex_shared 00000070 0000000001c05338 0000000001c05338 01b05338 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 18 .cpp_finidata 00000018 0000000001c053a8 0000000001c053a8 01b053a8 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 19 .data 00139974 0000000001c053c0 0000000001c053c0 01b053c0 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 20 .picdata 00000000 0000000001d3ed34 0000000001d3ed34 01c3ed34 2**0
> CONTENTS, ALLOC, LOAD, DATA
> 21 .bss 000778a8 0000000001d3ed38 0000000001d3ed38 01c3ed38 2**3
> ALLOC
> 22 .comment 000018d3 0000000000000000 0000000000000000 02477133 2**0
> CONTENTS, READONLY
> 23 .gnu_debuglink 00000018 0000000000000000 0000000000000000 02478b4b 2**0
> CONTENTS, READONLY
>
>
> On Tue, Mar 26, 2013 at 7:24 PM, David Chase <david.r.chase at oracle.com> wrote:
>> Well, it's not a concurrency bug, and my objcopy is 2.19 but otherwise provides identical info,
>> and the failure recurs by hand:
>>
>> gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo
>> gobjcopy:libjvm.so: File format not recognized
>>
>> libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped
>>
>> What sort of "file" is your libjvm.so?
>>
>> David
>>
>> On 2013-03-26, at 2:00 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>>> On Tue, Mar 26, 2013 at 6:43 PM, David Chase <david.r.chase at oracle.com> wrote:
>>>>
>>>> This is Solaris 11, not sure if that matters (configure didn't seem to think it was important enough to mention it).
>>>>
>>>> cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal.
>>>> ls says they are the same inode.
>>>>
>>>> Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying again (reconfiguring), but had the same result.
>>>>
>>>> Is it possible that this is some sort of a concurrency bug?
>>>
>>> I don't think so but if it should really be only a concurrency bug you
>>> should be able to manually do:
>>>
>>> gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo
>>>
>>>> I tried gmake JOBS=1 and it failed slightly differently.
>>>> I am cleaning, starting fresh with JOBS=1, I expect you will not hear from me for a while :-).
>>>>
>>>
>>> by the way, for my 'gobjcopy --info' prints:
>>>
>>> BFD header file version 2.15
>>> elf32-sparc
>>> (header big endian, data big endian)
>>> sparc
>>> elf64-sparc
>>> (header big endian, data big endian)
>>> sparc
>>> a.out-sunos-big
>>> (header big endian, data big endian)
>>> sparc
>>> elf64-little
>>> (header little endian, data little endian)
>>> sparc
>>> elf64-big
>>> (header big endian, data big endian)
>>> sparc
>>> elf32-little
>>> (header little endian, data little endian)
>>> sparc
>>> elf32-big
>>> (header big endian, data big endian)
>>> sparc
>>> srec
>>> (header endianness unknown, data endianness unknown)
>>> sparc
>>> symbolsrec
>>> (header endianness unknown, data endianness unknown)
>>> sparc
>>> tekhex
>>> (header endianness unknown, data endianness unknown)
>>> sparc
>>> binary
>>> (header endianness unknown, data endianness unknown)
>>> sparc
>>> ihex
>>> (header endianness unknown, data endianness unknown)
>>> sparc
>>>
>>> elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big
>>> sparc elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big
>>>
>>> elf32-little elf32-big srec symbolsrec tekhex binary ihex
>>> sparc elf32-little elf32-big srec symbolsrec tekhex binary ihex
>>
More information about the build-dev
mailing list