[Bug 221337] -fsanitize=address (asan) fails on i386

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Aug 16 17:08:38 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221337

--- Comment #5 from Dimitry Andric <dim at FreeBSD.org> ---
(In reply to Ed Maste from comment #3)
> Looking at libclang_rt.asan-i386.so it does have PT_TLS with 4-byte
> alignment, and perhaps that should be changed on general principle:
> 
> % readelf -l /usr/lib/clang/5.0.0/lib/freebsd/libclang_rt.asan-i386.so

Unfortunately, in most cases this .so is not used, but libclang_rt.asan-i386.a
is statically linked into the asan-instrumented executable.

For instance, I have this asan-instrumented executable, which is built on
FreeBSD 10/i386, using clang 4.0.1:

$ ldd ./asantest-f10-i386
./asantest-f10-i386:
        libthr.so.3 => /lib/libthr.so.3 (0x28124000)
        librt.so.1 => /usr/lib/librt.so.1 (0x28149000)
        libm.so.5 => /lib/libm.so.5 (0x2814f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2817a000)
        libc.so.7 => /lib/libc.so.7 (0x2818f000)

It has these program headers:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x00140 0x00140 R E 0x4
  INTERP         0x000174 0x08048174 0x08048174 0x00015 0x00015 R   0x1
      [Requesting program interpreter: /libexec/ld-elf.so.1]
  LOAD           0x000000 0x08048000 0x08048000 0xb2cec 0xb2cec R E 0x1000
  LOAD           0x0b36fc 0x080fc6fc 0x080fc6fc 0x02df4 0x459ed4 RW  0x1000
  DYNAMIC        0x0b39a8 0x080fc9a8 0x080fc9a8 0x00110 0x00110 RW  0x4
  NOTE           0x00018c 0x0804818c 0x0804818c 0x00030 0x00030 R   0x4
  TLS            0x0b36fc 0x080fc6fc 0x080fc6fc 0x00000 0x00018 R   0x4
  GNU_EH_FRAME   0x09dc48 0x080e5c48 0x080e5c48 0x028fc 0x028fc R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
  GNU_RELRO      0x0b36fc 0x080fc6fc 0x080fc6fc 0x00904 0x00904 R   0x1

Most align fields are set to 4, which seems logical on i386.

Meanwhile, I compared the program headers of libc.so.7 r319970:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x1660f8 0x1660f8 R E 0x1000
  LOAD           0x1660f8 0x001670f8 0x001670f8 0x06918 0x1b820 RW  0x1000
  DYNAMIC        0x168dd8 0x00169dd8 0x00169dd8 0x000c8 0x000c8 RW  0x4
  TLS            0x1660f8 0x001670f8 0x001670f8 0x00040 0x0005c R   0x4
  GNU_EH_FRAME   0x165cf8 0x00165cf8 0x00165cf8 0x000dc 0x000dc R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

and of libc.so.7 r319971:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x190368 0x190368 R E 0x1000
  LOAD           0x190368 0x00191368 0x00191368 0x07ab8 0x274e0 RW  0x1000
  DYNAMIC        0x194148 0x00195148 0x00195148 0x000d0 0x000d0 RW  0x4
  TLS            0x190368 0x00191368 0x00191368 0x00954 0x00970 R   0x4
  GNU_EH_FRAME   0x18ff68 0x0018ff68 0x0018ff68 0x000dc 0x000dc R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

What strikes me is that the size of the TLS section has greatly increased, from
0x40 to 0x954.  E.g. it has increased 370%, and also its size is no longer a
multiple of 16 bytes.

Maybe the new jemalloc adds a lot more 'static' TLS data?

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list