From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128994 invoked by alias); 4 Oct 2016 06:57:56 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 128952 invoked by uid 89); 4 Oct 2016 06:57:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=0xb7fd57c0, 0x00000000, 0x00000028, 20170 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Oct 2016 06:57:52 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C65F7C0528CC; Tue, 4 Oct 2016 06:57:51 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-55.ams2.redhat.com [10.36.116.55]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u946vmXi029480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Oct 2016 02:57:50 -0400 Date: Tue, 04 Oct 2016 06:57:00 -0000 From: Jan Kratochvil To: =?iso-2022-jp?B?GyRCSmlFX048GyhC?= Cc: gdb@sourceware.org Subject: Re: How to get value of gs:0xc with LTS note in coredump? Message-ID: <20161004065748.GA20294@host1.jankratochvil.net> References: <20161004012026.GA30611@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.7.0 (2016-08-17) X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00007.txt.bz2 On Tue, 04 Oct 2016 03:48:38 +0200, =1B$BJiE_N<=1B(B 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? >=20 > 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 li= ke: (gdb) p *(struct pthread *)0xb7fd57c0 $1 =3D {{header =3D {tcb =3D 0xb7fd57c0, dtv =3D 0xb7fd57c8, self =3D 0xb7f= d57c0, multiple_threads =3D 0, sysinfo =3D 4160576768, stack_guard =3D 4193= 608960, pointer_guard =3D 1631022810, gscope_flag =3D 0, __glibc_reserved1 = =3D 0, __private_tm =3D {0x0, 0x0, 0x0, 0x0}, __private_ss =3D 0x0}, __padd= ing =3D {0xf7fd2800, 0xf7fd2d08, 0xf7fd2800, 0x0, 0xf7fd5d00 <__kernel_vsys= call>, 0xf9f56500, 0x61376eda, 0x0 }}, list =3D {next =3D= 0xf7fc4184 <__stack_user>, prev =3D 0xf7fc4184 <__stack_user>}, tid =3D 20= 170, pid =3D 20170, {robust_list =3D {__next =3D 0xf7fd2870}, robust_head = =3D {list =3D 0xf7fd2870, futex_offset =3D -20, list_op_pending =3D 0x0}}, = cleanup =3D 0x0, cleanup_jmp_buf =3D 0xffffcb44, cancelhandling =3D 0, flag= s =3D 0, specific_1stblock =3D {{seq =3D 0, data =3D 0x0} }, specific =3D {0xf7fd288c, 0x0 }, specific_used =3D fa= lse, report_events =3D false, user_stack =3D true, stopped_start =3D false,= parent_cancelhandling =3D 0, lock =3D 0, setxid_futex =3D 0, cpuclock_offs= et =3D 2898183629324184, joinid =3D 0x0, result =3D 0x0, schedparam =3D {__= sched_priority =3D 0}, schedpolicy =3D 0, start_routine =3D 0x0, arg =3D 0x= 0, eventbuf =3D { eventmask =3D {event_bits =3D {0, 0}}, eventnum =3D TD_AL= L_EVENTS, eventdata =3D 0x0}, nextevent =3D 0x0, exc =3D {exception_class = =3D 0, exception_cleanup =3D 0x0, private_1 =3D 0, private_2 =3D 0}, stackb= lock =3D 0x0, stackblock_size =3D 4294953904, guardsize =3D 0, reported_gua= rdsize =3D 0, tpp =3D 0x0, res =3D {retrans =3D 0, retry =3D 0, options =3D= 0, nscount =3D 0, nsaddr_list =3D {{sin_family =3D 0, sin_port =3D 0, sin_= addr =3D {s_addr =3D 0}, sin_zero =3D "\000\000\000\000\000\000\000"}, {sin= _family =3D 0, sin_port =3D 0, sin_addr =3D { s_addr =3D 0}, sin_zero =3D "= \000\000\000\000\000\000\000"}, {sin_family =3D 0, sin_port =3D 0, sin_addr= =3D {s_addr =3D 0}, sin_zero =3D "\000\000\000\000\000\000\000"}}, id =3D = 0, dnsrch =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, defdname =3D '\000' , pfcode =3D 0, ndots =3D 0, nsort =3D 0, ipv6_unavail =3D 0= , unused =3D 0, sort_list =3D {{addr =3D { s_addr =3D 0}, mask =3D 0}, {add= r =3D {s_addr =3D 0}, mask =3D 0}, {addr =3D {s_addr =3D 0}, mask =3D 0}, {= addr =3D {s_addr =3D 0}, mask =3D 0}, { addr =3D {s_addr =3D 0}, mask =3D 0= }, {addr =3D {s_addr =3D 0}, mask =3D 0}, {addr =3D {s_addr =3D 0}, mask = =3D 0}, {addr =3D {s_addr =3D 0}, mask =3D 0}, {addr =3D {s_addr =3D 0}, ma= sk =3D 0}, {addr =3D {s_addr =3D 0}, mask =3D 0}}, qhook =3D 0x0, rhook =3D= 0x0, res_h_errno =3D 0, _vcsock =3D 0, _flags =3D 0, _u =3D {pad =3D '\000= ' , _ext =3D {nscount =3D 0, nsmap =3D {0, 0, 0}, nssocks= =3D {0, 0, 0}, nscount6 =3D 0, nsinit =3D 0, nsaddrs =3D {0x0, 0x0, 0x0}, = initstamp =3D 0}}}, end_padding =3D 0xf7fd2c84 ""}=20 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