From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45460 invoked by alias); 30 Oct 2017 13:44:47 -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 41890 invoked by uid 89); 30 Oct 2017 13:44:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-16.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,RCVD_IN_SBL,SPAM_URI,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:nabble.com, throughout, boards, H*r:14.3.361 X-Spam-User: qpsmtpd, 2 recipients X-HELO: 5pmail.ess.barracuda.com Received: from 5pmail.ess.barracuda.com (HELO 5pmail.ess.barracuda.com) (64.235.154.203) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Oct 2017 13:44:43 +0000 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1403.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 30 Oct 2017 13:43:49 +0000 Received: from [10.20.78.122] (10.20.78.122) by mips01.mipstec.com (10.20.43.31) with Microsoft SMTP Server id 14.3.361.1; Mon, 30 Oct 2017 06:36:10 -0700 Date: Mon, 30 Oct 2017 13:44:00 -0000 From: "Maciej W. Rozycki" To: Djordje Todorovic CC: Pedro Alves , , , "nemanja.popov@rt-rk.com" , , "Ananthakrishna Sowda (asowda)" , Nikola Prica Subject: Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file In-Reply-To: <64ad38a4-b8ae-912e-45d6-7048135ada2e@rt-rk.com> Message-ID: References: <74618d56-fa31-4cfe-329f-6a9078bac92b@rt-rk.com> <724f0bc9-6744-a915-d19d-77db7e9ce514@rt-rk.com> <64ad38a4-b8ae-912e-45d6-7048135ada2e@rt-rk.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-BESS-ID: 1509371027-321459-5573-220660-1 X-BESS-VER: 2017.12-r1709122024 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.186420 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status:1 X-SW-Source: 2017-10/txt/msg00890.txt.bz2 Hi Djordje, > > 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. > > 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 MIPS 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 not 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 file 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 *note) > break; > > case 136: /* sizeof(struct elf_prpsinfo) on Linux/x86_64 */ > - elf_tdata (abfd)->core->pid > - = bfd_get_32 (abfd, note->descdata + 24); > + //elf_tdata (abfd)->core->pid > + // = bfd_get_32 (abfd, note->descdata + 24); > elf_tdata (abfd)->core->program > = _bfd_elfcore_strndup (abfd, note->descdata + 40, 16); > elf_tdata (abfd)->core->command > > 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/tls-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/tls-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/gdb.threads/tls-core/tls-core'. > Program terminated with signal SIGTRAP, Trace/breakpoint trap. > #0 thread_proc (arg=0x0) 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/tls-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/tls-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/gdb.threads/tls-core/tls-core'. > Program terminated with signal SIGTRAP, Trace/breakpoint trap. > #0 thread_proc (arg=0x0) 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 = 0xdeadbeef > > Exactly the same situation I have reproduced on MIPS platforms. Have I > missed something? I'll see if I can reproduce it with the x86-64 target and that may help me understand why I don't see it with the MIPS one. > Regarding fetching value of TLS variable with cross or Multiarch GDB, we > actually 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 cross 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 changes 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. Thank you for the reference, and indeed in this case, with the problem being dealt with already, I'm even more confident that having it recorded as a known failure is the right way. But that needs an existing issue report in our Bugzilla to refer to. As you have been handling this already can you file one please? Once we have an issue number, we can then: if [is_remote target] { setup_kfail "gdb/..." "*-*-*" } ahead of the offending case. Overall we must never gratuitously cause new FAILs to appear in testing with new test cases -- either the causing issue should be fixed, or the problem KFAILed or XFAILed as appropriate, depending on the circumstances. I'm off throughout this week and this is my last reply in this thread until I am back. Can you please use the time to enter the bug report, and can you also tell me if your copyright assignment has been sorted out with FSF? Maciej