From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104970 invoked by alias); 4 Oct 2016 17:06:47 -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 104957 invoked by uid 89); 4 Oct 2016 17:06:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.3 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,FREEMAIL_FROM,GARBLED_BODY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Safe, safe!, dongliang, Safe! X-HELO: mail-oi0-f45.google.com Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com) (209.85.218.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Oct 2016 17:06:45 +0000 Received: by mail-oi0-f45.google.com with SMTP id d132so40516733oib.2 for ; Tue, 04 Oct 2016 10:06:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rGYqGxajBiRgavG1gFTcBKs2iGf3sZ2/oYE6dvgjNN8=; b=fiUUfMWlbg+AhKeUmBGNBNklp1Ac6HWXZnfuQDRk7i/0fdLG11sfFP0OJCNVQO2khJ gtaWKe5a6M2ZNajCbhxgeqqztXuEjFgWaEMOdOIJPRILXpC+Ztp6EWR86CNuhOMIJyGx EoqcfBUOkv91aakQJ6Yya+VCFFmtMkyW8DJM3Ob6FHTtJ/rJWwmG57+mP0I3i3INr+4C AVphcX9JqOAsr2z3ki9sd8jIAE+J0x1KJxPIpKTSkD6YNIJRtH1bMxqMqKM3OrEAgnrD cl/AheibpwrY59roEBJONnvJRO+UwZ4JDu7/65zySLv05egYdwXENlwm6mzYQWIKYk43 zXTA== X-Gm-Message-State: AA6/9Rn6CfcGQiX+HKxGqtsemF3mvu7GxHCxXsicOurRBcnb97BT8EuM6VUjp1p6BjINSYldy9ZL5l8KmyTjsQ== X-Received: by 10.157.27.99 with SMTP id l90mr3231683otl.4.1475600803297; Tue, 04 Oct 2016 10:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.97.136 with HTTP; Tue, 4 Oct 2016 10:06:12 -0700 (PDT) In-Reply-To: <20161004065748.GA20294@host1.jankratochvil.net> References: <20161004012026.GA30611@host1.jankratochvil.net> <20161004065748.GA20294@host1.jankratochvil.net> From: =?UTF-8?B?5oWV5Yas5Lqu?= Date: Tue, 04 Oct 2016 17:06:00 -0000 Message-ID: Subject: Re: How to get value of gs:0xc with LTS note in coredump? To: Jan Kratochvil Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00010.txt.bz2 2016-10-04 2:57 GMT-04:00 Jan Kratochvil : > On Tue, 04 Oct 2016 03:48:38 +0200, =E6=85=95=E5=86=AC=E4=BA=AE 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 addre= ss > 0xb7fd57c0. You can analyze where the address points to, it should look = like: > > (gdb) p *(struct pthread *)0xb7fd57c0 > $1 =3D {{header =3D {tcb =3D 0xb7fd57c0, dtv =3D 0xb7fd57c8, self =3D 0xb= 7fd57c0, multiple_threads =3D 0, sysinfo =3D 4160576768, stack_guard =3D 41= 93608960, pointer_guard =3D 1631022810, gscope_flag =3D 0, __glibc_reserved= 1 =3D 0, __private_tm =3D {0x0, 0x0, 0x0, 0x0}, __private_ss =3D 0x0}, __pa= dding =3D {0xf7fd2800, 0xf7fd2d08, 0xf7fd2800, 0x0, 0xf7fd5d00 <__kernel_vs= yscall>, 0xf9f56500, 0x61376eda, 0x0 }}, list =3D {next = =3D 0xf7fc4184 <__stack_user>, prev =3D 0xf7fc4184 <__stack_user>}, tid =3D= 20170, pid =3D 20170, {robust_list =3D {__next =3D 0xf7fd2870}, robust_hea= d =3D {list =3D 0xf7fd2870, futex_offset =3D -20, list_op_pending =3D 0x0}}= , cleanup =3D 0x0, cleanup_jmp_buf =3D 0xffffcb44, cancelhandling =3D 0, fl= ags =3D 0, specific_1stblock =3D {{seq =3D 0, data =3D 0x0} }, specific =3D {0xf7fd288c, 0x0 }, specific_used =3D = false, report_events =3D false, user_stack =3D true, stopped_start =3D fals= e, parent_cancelhandling =3D 0, lock =3D 0, setxid_futex =3D 0, cpuclock_of= fset =3D 2898183629324184, joinid =3D 0x0, result =3D 0x0, schedparam =3D {= __sched_priority =3D 0}, schedpolicy =3D 0, start_routine =3D 0x0, arg =3D = 0x0, eventbuf =3D { eventmask =3D {event_bits =3D {0, 0}}, eventnum =3D TD_= ALL_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}, stack= block =3D 0x0, stackblock_size =3D 4294953904, guardsize =3D 0, reported_gu= ardsize =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, s= in_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},= {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}, {addr =3D {s_addr =3D 0},= mask =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}, nsso= cks =3D {0, 0, 0}, nscount6 =3D 0, nsinit =3D 0, nsaddrs =3D {0x0, 0x0, 0x0= }, initstamp =3D 0}}}, end_padding =3D 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 tr= y to > compile some code. > > 80484dd: 65 a1 f8 ff ff ff mov %gs:0xfffffff8,%eax ; tha= t 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