From: 慕冬亮 <mudongliangabcd@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: How to get value of gs:0xc with LTS note in coredump?
Date: Tue, 04 Oct 2016 17:06:00 -0000 [thread overview]
Message-ID: <CAD-N9QUgwnLYCcOQOt0LNvtPbE_-LFHRp8-KWsO+vuwmurENKw@mail.gmail.com> (raw)
In-Reply-To: <20161004065748.GA20294@host1.jankratochvil.net>
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
prev parent reply other threads:[~2016-10-04 17:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-04 1:00 慕冬亮
2016-10-04 1:20 ` Jan Kratochvil
2016-10-04 1:49 ` 慕冬亮
2016-10-04 6:57 ` Jan Kratochvil
2016-10-04 17:06 ` 慕冬亮 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD-N9QUgwnLYCcOQOt0LNvtPbE_-LFHRp8-KWsO+vuwmurENKw@mail.gmail.com \
--to=mudongliangabcd@gmail.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox