https://bugs.llvm.org/show_bug.cgi?id=46110
Bug ID: 46110
Summary: Specifying -Ttext <altaddr> leaves data loaded at
default text load address
Product: lld
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: nicholas.h.briggs+l...@gmail.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
Using the following minimal C program (/tmp/foo.c), on a system running
FreeBSD 12.1-RELEASE-p5 GENERIC i386
int main(int argc, char *argv[]) {
return(1);
}
Compiling/linking with
$ clang --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM
8.0.1)
Target: i386-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin
$ clang -o /tmp/foo8 -static -Ttext 0x38000000 /tmp/foo.c
$ readelf -l /tmp/foo8
Elf file type is EXEC (Executable file)
Entry point 0x38000000
There are 11 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x37fff034 0x37fff034 0x00160 0x00160 R 0x4
LOAD 0x000000 0x37fff000 0x37fff000 0x00194 0x00194 R 0x1000
LOAD 0x001000 0x38000000 0x38000000 0x64510 0x64510 R E 0x1000
LOAD 0x066000 0x38065000 0x38065000 0x08578 0x08578 R 0x1000
LOAD 0x06f000 0x3806e000 0x3806e000 0x00030 0x00030 R E 0x1000
LOAD 0x070000 0x3806f000 0x3806f000 0x03990 0x161d1 RW 0x1000
TLS 0x073000 0x38072000 0x38072000 0x00970 0x00980 R 0x10
GNU_RELRO 0x073000 0x38072000 0x38072000 0x00990 0x01000 R 0x1
GNU_EH_FRAME 0x06e52c 0x3806d52c 0x3806d52c 0x00014 0x00014 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0
NOTE 0x066000 0x38065000 0x38065000 0x00030 0x00030 R 0x4
Section to Segment mapping:
Segment Sections...
00
01
02 .text
03 .note.tag .rel.plt .rodata .eh_frame_hdr .eh_frame
04 .init .fini .plt
05 .data .got.plt .tdata .tbss .ctors .dtors .jcr .init_array
.fini_array .bss
06 .tdata .tbss
07 .tdata .tbss .ctors .dtors .jcr .init_array .fini_array
08 .eh_frame_hdr
09
10 .note.tag
generates the expected program headers, with all virtual addresses up near
0x38000000.
However, with clang10 and clang-devel (11.0), the result is:
$ clang-devel -o /tmp/foo11 -static -Ttext 0x38000000 /tmp/foo.c
$ readelf -l /tmp/foo11
Elf file type is EXEC (Executable file)
Entry point 0x38000000
There are 12 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x00400034 0x00400034 0x00180 0x00180 R 0x4
LOAD 0x000000 0x00400000 0x00400000 0x001b4 0x001b4 R 0x1000
<<<<
LOAD 0x001000 0x38000000 0x38000000 0x64510 0x64510 R E 0x1000
LOAD 0x065510 0x38065510 0x38065510 0x085d0 0x085d0 R 0x1000
LOAD 0x06dae0 0x3806eae0 0x3806eae0 0x00030 0x00030 R E 0x1000
LOAD 0x06db10 0x3806fb10 0x3806fb10 0x00990 0x00990 RW 0x1000
LOAD 0x06e4a0 0x380714a0 0x380714a0 0x02420 0x14604 RW 0x1000
TLS 0x06db10 0x3806fb10 0x3806fb10 0x00970 0x00980 R 0x10
GNU_RELRO 0x06db10 0x3806fb10 0x3806fb10 0x00990 0x014f0 R 0x1
GNU_EH_FRAME 0x06da6c 0x3806da6c 0x3806da6c 0x0001c 0x0001c R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0
NOTE 0x065510 0x38065510 0x38065510 0x00030 0x00030 R 0x4
Section to Segment mapping:
Segment Sections...
00
01
02 .text
03 .note.tag .rel.dyn .rodata .eh_frame_hdr .eh_frame
04 .init .fini .iplt
05 .tdata .tbss .ctors .dtors .jcr .init_array .fini_array
06 .data .got.plt .bss
07 .tdata .tbss
08 .tdata .tbss .ctors .dtors .jcr .init_array .fini_array
09 .eh_frame_hdr
10
11 .note.tag
where there is some small chunk of (read only) data loaded at the default load
address of 0x00400000 (see <<<< above).
I don't see a way of suppressing this. This makes it awkward to build Valgrind
with the later LLVM compiler/linker as Valgrind expects to be able to map the
guest program at its default base address, but it finds that already occupied
by data mapped from itself.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
