From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78197 invoked by alias); 25 Oct 2017 22:40:38 -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 78122 invoked by uid 89); 25 Oct 2017 22:40:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=recall 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.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Oct 2017 22:40:27 +0000 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1412.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 25 Oct 2017 22:39:31 +0000 Received: from [10.20.78.65] (10.20.78.65) by mips01.mipstec.com (10.20.43.31) with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 15:37:32 -0700 Date: Wed, 25 Oct 2017 22:40:00 -0000 From: "Maciej W. Rozycki" To: Djordje Todorovic , Pedro Alves CC: , , "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: <724f0bc9-6744-a915-d19d-77db7e9ce514@rt-rk.com> Message-ID: References: <74618d56-fa31-4cfe-329f-6a9078bac92b@rt-rk.com> <724f0bc9-6744-a915-d19d-77db7e9ce514@rt-rk.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BESS-ID: 1508971170-452060-20892-163746-5 X-BESS-VER: 2017.12.1-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.186293 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/msg00786.txt.bz2 Hi Djordje (and Pedro, see below), > Please notice that I have reformatted patches 1/3 and 3/3, according=20 > your comments, and also tweaked a little bit patch 3/3. Thank you. There's still a small nit remaining WRT 1/3, but as I have=20 noted in a separate reply I'll handle it myself when committing. > Regarding patch 3/3, as Pedro said, currently =E2=80=9Cthread=E2=80=9D fu= nction 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=20 ago I observed GDB prefers LWPID over PID if available) I ran your test=20 case with the code changes removed and the test has still passed across=20 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= =20 written and read (following the various issues discovered in the course of= =20 this review, including the n32 BFD fix I have cc-ed you on lately),=20 however that brings the question again about how you originally observed=20 the problem you've addressed. Is there another test scenario that can be=20 created? Also now that the issue of using `run' has been resolved, I have verified= =20 the test case with a cross-debugger against a remote target and the result= =20 is a FAIL like below: (gdb) file .../gdb/testsuite/outputs/gdb.threads/tls-core/tls-core Reading symbols from .../gdb/testsuite/outputs/gdb.threads/tls-core/tls-cor= e...done. (gdb) core .../gdb/testsuite/outputs/gdb.threads/tls-core/gcore.test warning: core file may not match specified executable file. [New LWP 8829] [New LWP 8828] Core was generated by `.../gdb/testsuite/output'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 thread_proc (arg=3D0x0) at .../gdb/testsuite/gdb.threads/tls-core.c:25 25 return arg; [Current thread is 1 (LWP 8829)] (gdb) PASS: gdb.threads/tls-core.exp: load generated corefile p/x foo Cannot find thread-local storage for LWP 8829, executable file .../gdb/test= suite/outputs/gdb.threads/tls-core/tls-core: Cannot find thread-local variables on this target (gdb) FAIL: gdb.threads/tls-core.exp: print thread-local storage variable which I am fairly sure that is related (along with the "core file may not=20 match specified executable file." message) to an attempt to use native=20 `libthread_db'. Pedro, do I remember correctly it was you who recently mentioned (maybe=20 at the Cauldron) the need to have the issue of using `libthread_db' in=20 cross-debugging correctly addressed? For the time being I think we want=20 to KFAIL this test case if [is_remote target] (in its recently cleaned-up=20 meaning, as the test case actually succeeds with `native-gdbserver') --=20 but do we have a tracking bug already? Maciej