Re: How to get value of gs:0xc with LTS note in coredump?

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 04 Oct 2016 03:48:38 +0200, 慕冬亮 wrote:
> I need to analyze this note entry in my C code. How is it arranged by
> kernel or gdb?
> And what's the data structure for every item in this entry?
> 
> LINUX                 48  386_TLS
>     index: 6, base: 0xb7fd57c0, limit: 0x000fffff, flags: 0x00000051
>     index: 7, base: 0x00000000, limit: 0x00000000, flags: 0x00000028
>     index: 8, base: 0x00000000, limit: 0x00000000, flags: 0x00000028

Do you really want to analyze _the_note_?  There is only useful the address
0xb7fd57c0.  You can analyze where the address points to, it should look like:

(gdb) p *(struct pthread *)0xb7fd57c0
$1 = {{header = {tcb = 0xb7fd57c0, dtv = 0xb7fd57c8, self = 0xb7fd57c0, multiple_threads = 0, sysinfo = 4160576768, stack_guard = 4193608960, pointer_guard = 1631022810, gscope_flag = 0, __glibc_reserved1 = 0, __private_tm = {0x0, 0x0, 0x0, 0x0}, __private_ss = 0x0}, __padding = {0xf7fd2800, 0xf7fd2d08, 0xf7fd2800, 0x0, 0xf7fd5d00 <__kernel_vsyscall>, 0xf9f56500, 0x61376eda, 0x0 <repeats 17 times>}}, list = {next = 0xf7fc4184 <__stack_user>, prev = 0xf7fc4184 <__stack_user>}, tid = 20170, pid = 20170, {robust_list = {__next = 0xf7fd2870}, robust_head = {list = 0xf7fd2870, futex_offset = -20, list_op_pending = 0x0}}, cleanup = 0x0, cleanup_jmp_buf = 0xffffcb44, cancelhandling = 0, flags = 0, specific_1stblock = {{seq = 0, data = 0x0} <repeats 32 times>}, specific = {0xf7fd288c, 0x0 <repeats 31 times>}, specific_used = false, report_events = false, user_stack = true, stopped_start = false, parent_cancelhandling = 0, lock = 0, setxid_futex = 0, cpuclock_offset = 2898183629324184, joinid = 0x0, result = 0x0, schedparam = {__sched_priority = 0}, schedpolicy = 0, start_routine = 0x0, arg = 0x0, eventbuf = { eventmask = {event_bits = {0, 0}}, eventnum = TD_ALL_EVENTS, eventdata = 0x0}, nextevent = 0x0, exc = {exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = 0}, stackblock = 0x0, stackblock_size = 4294953904, guardsize = 0, reported_guardsize = 0, tpp = 0x0, res = {retrans = 0, retry = 0, options = 0, nscount = 0, nsaddr_list = {{sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, {sin_family = 0, sin_port = 0, sin_addr = { s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}}, id = 0, dnsrch = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, defdname = '\000' <repeats 255 times>, pfcode = 0, ndots = 0, nsort = 0, ipv6_unavail = 0, unused = 0, sort_list = {{addr = { s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, { addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}}, qhook = 0x0, rhook = 0x0, res_h_errno = 0, _vcsock = 0, _flags = 0, _u = {pad = '\000' <repeats 51 times>, _ext = {nscount = 0, nsmap = {0, 0, 0}, nssocks = {0, 0, 0}, nscount6 = 0, nsinit = 0, nsaddrs = {0x0, 0x0, 0x0}, initstamp = 0}}}, end_padding = 0xf7fd2c84 ""} 

But most of the interesting information is usually in application TLS
variables which are _under_ this address:
$ readelf -s executable|grep TLS
    59: 00000000     4 TLS     GLOBAL DEFAULT   19 x
    70: 00000004     4 TLS     GLOBAL DEFAULT   19 y
That address 0 and 4 are shifted down from the pthread_self(), you can try to
compile some code.

 80484dd:       65 a1 f8 ff ff ff       mov    %gs:0xfffffff8,%eax  ; that is 'x' at -8


Jan