[llvm-bugs] [Bug 46110] New: Specifying -Ttext <altaddr> leaves data loaded at default text load address

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: nicholas.h.briggs+llvm at gmail.com
                CC: llvm-bugs at lists.llvm.org, smithp352 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200527/af261678/attachment-0001.html>