| Summary: | linker doesn't recognize an ELF library. | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Pawel Sikora <pluto> |
| Component: | ld | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bug-binutils, scp |
| Priority: | P2 | ||
| Version: | 2.16 | ||
| Target Milestone: | --- | ||
| Host: | Target: | sparc-sun-solaris2.9 | |
| Build: | x86_64-gnu-linux | Last reconfirmed: | |
| Attachments: |
libbug.so.cc from example in previous comment
libbug.so.CC from previous example libbug.so.ld from previous example Fix determination of valid section indicies |
||
$ eu-readelf -h libcmodel.so ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: SPARC Version: 1 (current) Entry point address: 0x94 Start of program headers: 52 (bytes into file) Start of section headers: 337668 (bytes into file) Flags: Size of this header: 52 (bytes) Size of program header entries: 32 (bytes) Number of program headers entries: 3 Size of section header entries: 40 (bytes) Number of section headers entries: 25 Section header string table index: 23 strip also can't handle this precompiled external library. $ sparc-sun-solaris2.9-strip -g libcmodel.so --verbose sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized in general binutils works. $ :> dummy.cpp $ sparc-sun-solaris2.9-g++ dummy.cpp -shared -o libdummy.so $ sparc-sun-solaris2.9-strip -g libdummy.so --verbose copy from `libdummy.so' [elf32-sparc] to `stTTbQEv' [elf32-sparc] Subject: Re: linker doesn't recognize an ELF library.
Hi Pawel,
> strip also can't handle this precompiled external library.
>
> $ sparc-sun-solaris2.9-strip -g libcmodel.so --verbose
> sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized
How was this libcmodel.so file created ?
Are you able to create a small test case that builds an unrecognizable
file so that we can test binutils locally ?
Cheers
Nick
(In reply to comment #3) > Subject: Re: linker doesn't recognize an ELF library. > > Hi Pawel, > > > strip also can't handle this precompiled external library. > > > > $ sparc-sun-solaris2.9-strip -g libcmodel.so --verbose > > sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized > > How was this libcmodel.so file created ? I don't know. It's a commercial closed source library which works perfectly with native solaris linker/stripper and doesn't work with gnu/crossbinutils-2.16.91.0.7 On monday I will check our NDAs and try to attach this weird ELF library to this bug report for future tests. Subject: Re: linker doesn't recognize an ELF library.
Hi Pawel,
> I don't know. It's a commercial closed source library
> which works perfectly with native solaris linker/stripper
> and doesn't work with gnu/crossbinutils-2.16.91.0.7
> On monday I will check our NDAs and try to attach
> this weird ELF library to this bug report for future tests.
If the NDA does not allow you to supply a test file, then there is not
much that we will able to do. One thing you could try though is to run
"readelf -a -w libcmodel.so" and see if readelf reports any errors or
problems in the file. (I am assuming that the file is somehow not quite
conformant to the ELF standard and this is why it is not being recognised).
Is the supplier of the file Cisco by any chance ? We had another bug
report recently about binutils not being able to handle some files made
by Cisco and a patch was developed to solve the problem.
Cheers
Nick
(In reply to comment #5) > If the NDA does not allow you to supply a test file, then there is not > much that we will able to do. One thing you could try though is to run > "readelf -a -w libcmodel.so" and see if readelf reports any errors or > problems in the file. (I am assuming that the file is somehow not quite > conformant to the ELF standard and this is why it is not being recognised). readelf -a -w doesn't report any warnings/errors. > Is the supplier of the file Cisco by any chance ? i'm sure it's not a cisco product. it was compiled with sun workshop studio. i've checked an older version (2.15) of binutils and it works. current 2.16 fails... $ sparc-sun-solaris2.9-strip libcmodel.so -v --strip-unneeded sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized so, strip with older (2.15) version... $ /usr/local/solaris-cross/bin/sparc-sun-solaris2.8-strip libcmodel.so \ -v --strip-unneeded copy from libcmodel.so(elf32-sparc) to stCGYfYS(elf32-sparc) ...and test again with 2.16... $ sparc-sun-solaris2.9-strip libcmodel.so -v --strip-unneeded copy from `libcmodel.so' [elf32-sparc] to `stopZxTe' [elf32-sparc] BFD: stopZxTe: warning: allocated section `.bss' not in segment library stripped by 2.15 doesn't contain some information: --- libcmodel.so.orig.txt 2006-05-09 11:10:37.000000000 +0200 +++ libcmodel.so.txt 2006-05-09 11:22:22.000000000 +0200 @@ -1,6 +1,6 @@ -libcmodel.so.orig: file format elf32-sparc -libcmodel.so.orig +libcmodel.so: file format elf32-sparc +libcmodel.so architecture: sparc, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00000094 @@ -8,10 +8,10 @@ Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16 filesz 0x000504e9 memsz 0x000504e9 flags r-x - LOAD off 0x000504ec vaddr 0x000604ec paddr 0x00000000 align 2**16 + LOAD off 0x000504ec vaddr 0x000604ec paddr 0x000604ec align 2**16 filesz 0x000020f8 memsz 0x000020f8 flags rwx - DYNAMIC off 0x00051748 vaddr 0x00061748 paddr 0x00000000 align 2**0 - filesz 0x000000e0 memsz 0x00000000 flags rwx + DYNAMIC off 0x00051748 vaddr 0x00061748 paddr 0x00061748 align 2**2 + filesz 0x000000e0 memsz 0x000000e0 flags rwx Dynamic Section: NEEDED libCstd.so.1 @@ -42,15 +42,6 @@ FLAGS_1 0x8000 PLTGOT 0x60a6c -Version References: - required from libCstd.so.1: - 0x0d279a21 0x02 00 SUNW_1.1.1 - 0x0a3d2791 0x00 00 SUNW_1.1 - required from libCrun.so.1: - 0x0a3d2791 0x00 00 SUNW_1.1 - required from libdl.so.1: - 0x077a74f3 0x00 00 SISCD_2.3 - Sections: Idx Name Size VMA LMA File off Algn 0 .hash 000014f0 00000094 00000094 00000094 2**2 @@ -97,7 +88,7 @@ CONTENTS, ALLOC, LOAD, DATA 21 .bss 00000000 000625e4 000625e4 000525e4 2**0 ALLOC - 22 .comment 0000002c 00000000 00000000 000526d5 2**0 + 22 .comment 0000002c 00000000 00000000 000525e4 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols
I have just run into what I believe is the same problem. It appears to be due to
a new version of the Sun ld (/usr/ccs/bin/ld) which was installed recently on
our Solaris8 systems as part of trying to patch up the Sun ONE Studio 8 and Sun
Studio 10 compiler suites. Sun's ld will happily recognize the shared objects
produced by the new ld, but binutil 2.16 (and 2.16.1)'s bfd library will not.
Further investigation showed that the shared library in question was the only
one in our codebase with this problem, and it happens to be the only shared
library in our codebase in which the source files (i.e. *.o object files going
in) were compiled with the Sun C compiler), but the shared library was created
using the Sun C++ driver (i.e. CC -G ...). Furthermore, the problem occurs
because /usr/ccs/bin/ld is invoked with the option
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1, which
contains exception handling support. Invoking the equivalent /usr/ccs/bin/ld
command minus that command line option, the resulting library is handled without
problem by binutils.
The workaround for us has been to create the shared library using cc -G instead
of CC -G in the case where there are no C++ sources in the shared library.
I should emphasize that /usr/ccs/bin/ld is perfectly happy with the resulting
shared objects no matter how they were created.
Here's a few more details:
% ls -l /usr/ccs/bin/ld
-rwxr-xr-x 1 root bin 7824 Oct 27 2005 /usr/ccs/bin/ld*
% cksum /usr/ccs/bin/ld
3259439703 7824 /usr/ccs/bin/ld
% ls -l /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1
-rwxrwxr-x 1 root sys 12320 Mar 13 2003
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1*
% cksum /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1
4099598650 12320 /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1
And an example which will reproduce the problem (assuming you have the right
versions of Sun stuff...)
First create a simple object for a shared lib:
% cat bug.c
int foo()
{
return 1;
}
% cc -KPIC -c bug.c
Make a shared library using the cc driver
% cc -# -G -o libbug.so.cc bug.o
### Note: NLSPATH =
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### command line files and options (expanded):
### -G bug.o -o libbug.so.cc
### Note: LD_LIBRARY_PATH = /home/scp/lib
### Note: LD_RUN_PATH = <null>
/usr/ccs/bin/ld /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crti.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/values-xa.o -o libbug.so.cc -G
bug.o -Y
"P,/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib:/usr/ccs/lib:/usr/lib" -Qy
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crtn.o
Check and see that binutils likes the file
% /usr/local/pkg/binutils-2.16.1/bin/nm libbug.so.cc
000102e8 b Bbss.bss
...
Now do the same using the CC (C++) driver. First a dryrun to see the ld command,
and then the real command.
% CC -dryrun -G -o libbug.so.CC bug.o
### command line files and options (expanded):
### -dryrun -G -o libbug.so.CC bug.o -xcode=pic13
### CC: Note: NLSPATH =
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### CC: Note: LD_LIBRARY_PATH = /home/scp/lib
### CC: Note: LD_RUN_PATH = (null)
### CC: Note: LD_OPTIONS = (null)
/usr/ccs/bin/ld
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libCCexcept.so.1
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libldstab_ws.so
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libldstab_ws.so -dy
-G
-R/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib
-o libbug.so.CC /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crti.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrti.o bug.o -Y
P,/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib:/usr/ccs/lib:/usr/lib
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrtn.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crtn.o >&/tmp/ld.24218.0.err
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/c++filt -filt=no%stdlib
</tmp/ld.24218.0.err >>/tmp/c++filt.24218.1.err
rm /tmp/ld.24218.0.err
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/stdlibfilt -stderr
</tmp/c++filt.24218.1.err
rm /tmp/c++filt.24218.1.err
% CC -G -o libbug.so.CC bug.o
And now check that binutils doesn't like this shared object
% /usr/local/pkg/binutils-2.16.1/bin/nm libbug.so.CC
/usr/local/pkg/binutils-2.16.1/bin/nm: libbug.so.CC: File format not recognized
Finally, cut and paste from dryrun above, removing the
-zld32=-S.../libCCexcept.so.1 ...
% /usr/ccs/bin/ld
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libCCexcept.so.1
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libldstab_ws.so
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libldstab_ws.so -dy
-G
-R/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib
-o libbug.so.ld /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crti.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrti.o bug.o -Y
P,/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib:/usr/ccs/lib:/usr/lib
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrtn.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crtn.o
And this time binutils likes it
% /usr/local/pkg/binutils-2.16.1/bin/nm libbug.so.ld
000106f0 b Bbss.bss
...
I will attach the three different shared objects, in the event that some
maintainer has access to an appropriate Solaris/Sparc system and can determine
what the issue is.
Hope that helps.
Created attachment 1013 [details]
libbug.so.cc from example in previous comment
Created attachment 1014 [details]
libbug.so.CC from previous example
Created attachment 1015 [details]
libbug.so.ld from previous example
Subject: Re: linker doesn't recognize an ELF library. Hi Pawel, > I will attach the three different shared objects, in the event that some > maintainer has access to an appropriate Solaris/Sparc system and can determine > what the issue is. Thanks. That has allowed me to locate the problem. The libbug.so.CC file has a section named .exception_ranges which has an link value of 0xFF00. Normally the link value should be a valid index into the section table in the ELF binary, and the BFD library was detecting this discrepancy and treating the file as invalid. The bug however was that certain other special values are allowed in the index field. Namely values in the range of SHN_LOPROC (0xFF00) to SHN_HIOS (0xFF3F). So please could you try out the uploaded patch which I hope will correct the problem. It certainly works for me using libbug.so.CC file that you supplied. Cheers Nick bfd/ChangeLog 2006-05-10 Nick Clifton <nickc@redhat.com> PR ld/2607 * elfcode.h (valid_section_index_p): New function: Checks for a valid section index. Allows indicies in the range SHN_LOPROC to SHN_HIOS. (elf_object_p): Use valid_section_index_p. Created attachment 1016 [details]
Fix determination of valid section indicies
(In reply to comment #12) > Created an attachment (id=1016) > Fix determination of valid section indicies works for me :) Nick, That patch, applied against the 2.16.1 release source (with a little syntactic fudge by hand on the last hunk) seems to do the trick perfectly. Thank you! (I'll leave it to you or others to change the status of the this bug. Uh, duh, I should point out that it solves my problem. I cannot speak for Pawel... patch fixes all testcases. Subject: Re: linker doesn't recognize an ELF library.
Hi Pawel,
> pluto at agmk dot net wrote:
> works for me :)
Excellent - I have applied the patch to the mainline and the 2.17 branch
as well.
Cheers
Nick
|
$ file libcmodel.so libcmodel.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), stripped $ hexdump -n 256 libcmodel.so -C 00000000 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 |.ELF............| 00000010 00 03 00 02 00 00 00 01 00 00 00 94 00 00 00 34 |...............4| 00000020 00 05 27 04 00 00 00 00 00 34 00 20 00 03 00 28 |..'......4. ...(| 00000030 00 19 00 17 00 00 00 01 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 05 04 e9 00 05 04 e9 00 00 00 05 |................| 00000050 00 01 00 00 00 00 00 01 00 05 04 ec 00 06 04 ec |................| 00000060 00 00 00 00 00 00 20 f8 00 00 20 f8 00 00 00 07 |...... ... .....| 00000070 00 01 00 00 00 00 00 02 00 05 17 48 00 06 17 48 |...........H...H| 00000080 00 00 00 00 00 00 00 e0 00 00 00 00 00 00 00 07 |................| 00000090 00 00 00 00 00 00 02 a1 00 00 02 99 00 00 00 00 |................| 000000a0 00 00 00 01 00 00 00 03 00 00 00 04 00 00 00 06 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 09 |................| 000000c0 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 0b |................| 000000d0 00 00 00 0c 00 00 00 0e 00 00 00 00 00 00 00 0f |................| 000000e0 00 00 00 11 00 00 00 13 00 00 00 14 00 00 00 17 |................| 000000f0 00 00 00 00 00 00 00 19 00 00 00 1a 00 00 00 1c |................| $ sparc-sun-solaris2.9-ld libcmodel.so -o /dev/null --verbose GNU ld version 2.16.91.0.7 20060317 Supported emulations: elf32_sparc elf64_sparc using internal linker script: ================================================== /* Script for -z combreloc: combine and sort reloc sections */ OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc") OUTPUT_ARCH(sparc) ENTRY(_start) SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/usr/ccs/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); SECTIONS { /* Read-only sections, merged into text segment: */ PROVIDE (__executable_start = 0x10000); . = 0x10000 + SIZEOF_HEADERS; .interp : { *(.interp) } .hash : { *(.hash) } .dynsym : { *(.dynsym) } .dynstr : { *(.dynstr) } .gnu.version : { *(.gnu.version) } .gnu.version_d : { *(.gnu.version_d) } .gnu.version_r : { *(.gnu.version_r) } .rel.dyn : { *(.rel.init) *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) *(.rel.fini) *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) *(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*) *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) *(.rel.ctors) *(.rel.dtors) *(.rel.got) *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) } .rela.dyn : { *(.rela.init) *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) *(.rela.fini) *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) *(.rela.ctors) *(.rela.dtors) *(.rela.got) *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) } .rel.plt : { *(.rel.plt) } .rela.plt : { *(.rela.plt) } .init : { KEEP (*(.init)) } =0 .text : { *(.text .stub .text.* .gnu.linkonce.t.*) KEEP (*(.text.*personality*)) /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) } =0 .fini : { KEEP (*(.fini)) } =0 PROVIDE (__etext = .); PROVIDE (_etext = .); PROVIDE (etext = .); .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } .rodata1 : { *(.rodata1) } .eh_frame_hdr : { *(.eh_frame_hdr) } .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) } .gcc_except_table : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) } /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ . = ALIGN (0x10000) - ((0x10000 - .) & (0x10000 - 1)); . = DATA_SEGMENT_ALIGN (0x10000, 0x2000); /* Exception handling */ .eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) } .gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) } /* Thread Local Storage sections */ .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) } .preinit_array : { PROVIDE_HIDDEN (__preinit_array_start = .); KEEP (*(.preinit_array)) PROVIDE_HIDDEN (__preinit_array_end = .); } .init_array : { PROVIDE_HIDDEN (__init_array_start = .); KEEP (*(SORT(.init_array.*))) KEEP (*(.init_array)) PROVIDE_HIDDEN (__init_array_end = .); } .fini_array : { PROVIDE_HIDDEN (__fini_array_start = .); KEEP (*(.fini_array)) KEEP (*(SORT(.fini_array.*))) PROVIDE_HIDDEN (__fini_array_end = .); } .ctors : { /* gcc uses crtbegin.o to find the start of the constructors, so we make sure it is first. Because this is a wildcard, it doesn't matter if the user does not actually link against crtbegin.o; the linker won't look for a file to match a wildcard. The wildcard also means that it doesn't matter wh directory crtbegin.o is in. */ KEEP (*crtbegin*.o(.ctors)) /* We don't want to include the .ctor section from the crtend.o file until after the sorted ctors. The .ctor section from the crtend file contains the end of ctors marker and it must be last */ KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors)) KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) } .dtors : { KEEP (*crtbegin*.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) } .jcr : { KEEP (*(.jcr)) } .data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro* .gnu.linkonce.d.rel.ro.*) } .dynamic : { *(.dynamic) } . = DATA_SEGMENT_RELRO_END (0, .); .got : { *(.got.plt) *(.got) } .plt : { *(.plt) } .data : { *(.data .data.* .gnu.linkonce.d.*) KEEP (*(.gnu.linkonce.d.*personality*)) SORT(CONSTRUCTORS) } .data1 : { *(.data1) } _edata = .; PROVIDE (edata = .); __bss_start = .; .bss : { *(.dynbss) *(.bss .bss.* .gnu.linkonce.b.*) *(COMMON) /* Align here to ensure that the .bss section occupies space up to _end. Align after .bss to ensure correct alignment even if the .bss section disappears because there are no input sections. FIXME: Why do we need it? When there is no .bss section, we don't pad the .data section. */ . = ALIGN(. != 0 ? 8 : 1); } . = ALIGN(8); . = ALIGN(8); _end = .; PROVIDE (end = .); . = DATA_SEGMENT_END (.); /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } /DISCARD/ : { *(.note.GNU-stack) } } ================================================== attempt to open libcmodel.so succeeded opened script file libcmodel.so libcmodel.so: file not recognized: File format not recognized