https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221337
--- Comment #5 from Dimitry Andric <d...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
