From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66084 invoked by alias); 26 Oct 2017 11:22:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 66042 invoked by uid 89); 26 Oct 2017 11:21:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-15.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPAM_URI autolearn=ham version=3.3.2 spammy=reproduced, 12552, 12556 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail.rt-rk.com Received: from mx2.rt-rk.com (HELO mail.rt-rk.com) (89.216.37.149) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Oct 2017 11:21:57 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.rt-rk.com (Postfix) with ESMTP id 66D0F1A4996; Thu, 26 Oct 2017 13:21:54 +0200 (CEST) Received: from [10.10.13.94] (djole.domain.local [10.10.13.94]) by mail.rt-rk.com (Postfix) with ESMTPSA id 234671A4988; Thu, 26 Oct 2017 13:21:54 +0200 (CEST) Subject: Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file To: "Maciej W. Rozycki" , Pedro Alves Cc: binutils@sourceware.org, gdb-patches@sourceware.org, "nemanja.popov@rt-rk.com" , petar.jovanovic@rt-rk.com, "Ananthakrishna Sowda (asowda)" , Nikola Prica References: <74618d56-fa31-4cfe-329f-6a9078bac92b@rt-rk.com> <724f0bc9-6744-a915-d19d-77db7e9ce514@rt-rk.com> From: Djordje Todorovic Message-ID: <64ad38a4-b8ae-912e-45d6-7048135ada2e@rt-rk.com> Date: Thu, 26 Oct 2017 11:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-10/txt/msg00811.txt.bz2 Hi Maciej, > Thank you. There's still a small nit remaining WRT 1/3, but as I have > noted in a separate reply I'll handle it myself when committing. Thanks a lot! I really appreciate it! >> Regarding patch 3/3, as Pedro said, currently =E2=80=9Cthread=E2=80=9D f= unction has a=20 >> piece of code that is never going to be executed since core file is=20 >> going to be generated as soon as the first thread reaches the thread=20 >> function. So, since we are testing fetching value of TLS variable from= =20 >> core file, creating just a one thread in test case would be enough and=20 >> regarding that, I have cut unnecessary code from the function. > > Hmm, to understand how exactly the bug triggers (as you may recall long > ago I observed GDB prefers LWPID over PID if available) I ran your test > case with the code changes removed and the test has still passed across > the three ABIs. So it does not actually cover the case concerned here.= =20=20 > I still would like to keep it to verify the consistency between core files > written and read (following the various issues discovered in the course of > this review, including the n32 BFD fix I have cc-ed you on lately), > however that brings the question again about how you originally observed > the problem you've addressed. Is there another test scenario that can be > created? Thanks a lot, I saw that n32 BFD fix, and it is great! Actually, I have faced it when I tried to read value of TLS variable on MIP= S platforms (native). I agree with you that GDB prefers LWPID over PID if = available, but with no PID from core file GDB, at least on my boards, can n= ot read value of TLS variable. I have tried to do some observation on x86_= 64 native platform and commented piece of code for fetching PID from core f= ile like this: diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c index 6a5159d..9ee9231 100644 --- a/bfd/elf64-x86-64.c +++ b/bfd/elf64-x86-64.c @@ -415,8 +415,8 @@ elf_x86_64_grok_psinfo (bfd *abfd, Elf_Internal_Note *n= ote) break; case 136: /* sizeof(struct elf_prpsinfo) on Linux/x86_= 64 */ - elf_tdata (abfd)->core->pid - =3D bfd_get_32 (abfd, note->descdata + 24); + //elf_tdata (abfd)->core->pid + // =3D bfd_get_32 (abfd, note->descdata + 24); elf_tdata (abfd)->core->program =3D _bfd_elfcore_strndup (abfd, note->descdata + 40, 16); elf_tdata (abfd)->core->command =20 and rebuilt GDB (with "make clean" and "make"), the test case was FAIL: (gdb) file /home/rtrk/gdb/build_native/gdb/testsuite/outputs/gdb.threads/tl= s-core/tls-core Reading symbols from /home/rtrk/gdb/build_native/gdb/testsuite/outputs/gdb.= threads/tls-core/tls-core...done. (gdb) core /home/rtrk/gdb/build_native/gdb/testsuite/outputs/gdb.threads/tl= s-core/gcore.test [New LWP 12556] [New LWP 12552] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/home/rtrk/gdb/build_native/gdb/testsuite/outputs/gd= b.threads/tls-core/tls-core'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 thread_proc (arg=3D0x0) at /home/rtrk/gdb/build_native/gdb/testsuite/../= ../../binutils-gdb/gdb/testsuite/gdb.threads/tls-core.c:25 25 return arg; [Current thread is 1 (LWP 12556)] (gdb) PASS: gdb.threads/tls-core.exp: load generated corefile p/x foo Cannot find user-level thread for LWP 12556: generic error When I reverted this observation changes and rebuilt it again, GDB was able= to read value of TLS variable: (gdb) file /home/rtrk/gdb/build_native/gdb/testsuite/outputs/gdb.threads/tl= s-core/tls-core Reading symbols from /home/rtrk/gdb/build_native/gdb/testsuite/outputs/gdb.= threads/tls-core/tls-core...done. (gdb) core /home/rtrk/gdb/build_native/gdb/testsuite/outputs/gdb.threads/tl= s-core/gcore.test [New LWP 11099] [New LWP 11095] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/home/rtrk/gdb/build_native/gdb/testsuite/outputs/gd= b.threads/tls-core/tls-core'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 thread_proc (arg=3D0x0) at /home/rtrk/gdb/build_native/gdb/testsuite/../= ../../binutils-gdb/gdb/testsuite/gdb.threads/tls-core.c:25 25 return arg; [Current thread is 1 (Thread 0x7ffff77ef700 (LWP 11099))] (gdb) PASS: gdb.threads/tls-core.exp: load generated corefile p/x foo $1 =3D 0xdeadbeef Exactly the same situation I have reproduced on MIPS platforms. Have I miss= ed something? Regarding fetching value of TLS variable with cross or Multiarch GDB, we ac= tually had proposal for resolving that issue in GDB, where we proposed that= GDB can have its own "libthread_db" functions for getting TLS in case of c= ross debugging, where it is going to "simulate" "target" architecture, but = that code would be hard to maintain, because every changes in "libthread_db= " functions regarding particular architecture in GLIBC would take also chan= ges in GDB, so it was not accepted by community, reasonably (please briefly= see that thread: http://sourceware-org.1504.n7.nabble.com/PATCH-TLS-access= -support-in-cross-Linux-GDB-td452155.html). But yes, I also think in those = cases, test should be marked as known failure. Thanks, Djordje