This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


2016-10-04 2:57 GMT-04:00 Jan Kratochvil <jan.kratochvil@redhat.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
>

There are three entries in this note. I am not sure there is only one
useful entry in 32bit linux. What's your opinion?

And I need a data structure to represent each entry. Is this data
structure in /usr/inclucde/elf.h like Elf32_Nhdr?

Each thread has a note NT_386_LTS, yes? I need to attach such a base
address to each thread.

--
My best regards to you.

     No System Is Safe!
     Dongliang Mu


>
> Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]