tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Linking C++
There is a restriction in our ld.elf_so that it can only load two
segments.
Using devel/lld to link C++ objects on aarch64 creats a shlib with three
segments that then fails to load.
On aarch64 .init_array contains static constructors, on x86_64 they
are in .ctors.
What is expected to happen to delete or combine segments in a linker
to get down to two of them ? Hints on where to look in gcc or binutils
would be good.
An example on aarch64:
% readelf -l libjvm.so
Elf file type is DYN (Shared object file)
Entry point 0x3dbd40
There are 10 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x0000000000000230 0x0000000000000230 R 0x8
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000c7ca70 0x0000000000c7ca70 R E 0x10000
LOAD 0x0000000000c80000 0x0000000000c80000 0x0000000000c80000
0x0000000000095348 0x0000000000095348 RW 0x10000
LOAD 0x0000000000d20000 0x0000000000d20000 0x0000000000d20000
0x000000000002e270 0x000000000009cd40 RW 0x10000
TLS 0x0000000000c7ca70 0x0000000000c7ca70 0x0000000000c7ca70
0x0000000000000000 0x0000000000000028 R 0x8
DYNAMIC 0x0000000000d0d290 0x0000000000d0d290 0x0000000000d0d290
0x00000000000001d0 0x00000000000001d0 RW 0x8
GNU_RELRO 0x0000000000c80000 0x0000000000c80000 0x0000000000c80000
0x0000000000095348 0x0000000000096000 R 0x1
GNU_EH_FRAME 0x000000000027d2a0 0x000000000027d2a0 0x000000000027d2a0
0x000000000004864c 0x000000000004864c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
NOTE 0x0000000000000270 0x0000000000000270 0x0000000000000270
0x000000000000002c 0x000000000000002c R 0x4
Section to Segment mapping:
Segment Sections...
00
01 .note.netbsd.ident .note.netbsd.pax .dynsym .gnu.version .gnu.version_d .gnu.version_r .gnu.hash .hash .dynstr .rela.dyn .rela.plt .rodata .eh_frame_hdr .eh_frame .text .plt
02 .init_array .fini_array .jcr .data.rel.ro .dynamic .got
03 .data .got.plt .bss
04 .tbss
05 .dynamic
06 .init_array .fini_array .jcr .data.rel.ro .dynamic .got
07 .eh_frame_hdr
08
09 .note.netbsd.ident .note.netbsd.pax
The equivalent x86_64 shlib shows this:
% readelf -l libjvm.so
Elf file type is DYN (Shared object file)
Entry point 0x2683a0
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000001002928 0x0000000001002928 R E 0x200000
LOAD 0x0000000001002fb8 0x0000000001202fb8 0x0000000001202fb8
0x00000000000f3520 0x0000000000143100 RW 0x200000
DYNAMIC 0x00000000010bdc90 0x00000000012bdc90 0x00000000012bdc90
0x00000000000001f0 0x00000000000001f0 RW 0x8
NOTE 0x00000000010028fc 0x00000000010028fc 0x00000000010028fc
0x000000000000002c 0x000000000000002c R 0x4
TLS 0x0000000001002fb8 0x0000000001202fb8 0x0000000001202fb8
0x0000000000000000 0x0000000000000008 R 0x8
GNU_EH_FRAME 0x0000000000e4933c 0x0000000000e4933c 0x0000000000e4933c
0x000000000004b234 0x000000000004b234 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x0000000001002fb8 0x0000000001202fb8 0x0000000001202fb8
0x00000000000bb048 0x00000000000bb048 R 0x1
Section to Segment mapping:
Segment Sections...
00
01 .hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .note.netbsd.ident .note.netbsd.pax
02 .ctors .dtors .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
03 .dynamic
04 .note.netbsd.ident .note.netbsd.pax
05 .tbss
06 .eh_frame_hdr
07
08 .ctors .dtors .jcr .data.rel.ro .dynamic .got
Home |
Main Index |
Thread Index |
Old Index