From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28086 invoked by alias); 10 May 2013 14:31:03 -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 27987 invoked by uid 89); 10 May 2013 14:31:03 -0000 X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KHOP_THREADED,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-pd0-f180.google.com (HELO mail-pd0-f180.google.com) (209.85.192.180) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 10 May 2013 14:31:01 +0000 Received: by mail-pd0-f180.google.com with SMTP id t10so2834539pdi.39 for ; Fri, 10 May 2013 07:31:00 -0700 (PDT) X-Received: by 10.66.102.70 with SMTP id fm6mr17667595pab.164.1368196260225; Fri, 10 May 2013 07:31:00 -0700 (PDT) Received: from [192.168.1.100] ([180.160.37.25]) by mx.google.com with ESMTPSA id hp1sm3181595pac.3.2013.05.10.07.30.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 May 2013 07:30:58 -0700 (PDT) References: <87d2tcv0s0.fsf@kepler.schwinge.homeip.net> <87ehdpsip3.fsf@kepler.schwinge.homeip.net> <87a9o3nmw5.fsf@kepler.schwinge.homeip.net> In-Reply-To: <87a9o3nmw5.fsf@kepler.schwinge.homeip.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: Cc: "" , "" From: Hacklu Subject: Re: [GSoC2013] question about "improve the GDB port for GNU Hurd" Date: Fri, 10 May 2013 14:31:00 -0000 To: Thomas Schwinge X-SW-Source: 2013-05/txt/msg00052.txt.bz2 Hi. =E5=9C=A8 2013-5-10=EF=BC=8C18:35=EF=BC=8CThomas Schwinge =E5=86=99=E9=81=93=EF=BC=9A > Hi! >=20 > In the last days, I've been and still am rather busy with other > commitments, and unfortunately have not yet been able to continue working > with you on your GSoC application as well as the GDB patch you sent. > Starting Tuesday next week, I should be able to spend more time on that. Ok,I will waiting for your review on that application. >=20 > On Thu, 2 May 2013 20:50:03 +0800, =E9=99=86=E5=B2=B3 wrote: >> On Thu, May 2, 2013 at 7:51 PM, Thomas Schwinge wrote: >>=20 >>> You can clone hurd/web.git repository from Savannah, and check out the >>> toolchain/logs/master branch (which I have as a Git submodule on >>> toolchain/logs), and compare the >>> gdb/coulomb.SCHWINGE/test/gdb/testsuite/gdb.*/*.sum files with those you >>> got. >>=20 >> I will do the compare after I have finished the application. >=20 > Yes, please have a look at that. For example, do you get significantly > different test failures than I have, and how/why are they different? > Please be aware that the results from the GDB testsuite, especially when > run on GNU Hurd, are not completely "stable" (deterministic): as you can > see from the revisions of my test result files, some FAILs come and go > randomly, not related to any GDB code changes, or system environment > changes. That is, for two GDB test runs you'll get some different > results. (With time, you'll get used to quickly recognize and "ignore" > these...) ;-| Ah, I got it. >=20 > Oh, and if you want to read more about GDB's architecture and provenance, > I can recommend Stan Shebs' chapter in =C2=BBThe Architecture of Open Sou= rce > Applications=C2=AB, . That's just what I need. I am reading the these days. >=20 > Gr=C3=BC=C3=9Fe, > Thomas Yue Lu (=E9=99=86=E5=B2=B3) >From gdb-return-42126-listarch-gdb=sources.redhat.com@sourceware.org Mon May 13 14:46:03 2013 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 13651 invoked by alias); 13 May 2013 14:46:02 -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 Delivered-To: mailing list gdb@sourceware.org Received: (qmail 13574 invoked by uid 89); 13 May 2013 14:46:01 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS,TW_TR autolearn=unavailable version=3.3.1 Received: from hop-nat-141.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 13 May 2013 14:46:01 +0000 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DEjtkL022546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 May 2013 10:45:55 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 13 May 2013 10:45:49 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DEjl43005982; Mon, 13 May 2013 10:45:47 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id F3E205AFE16; Mon, 13 May 2013 10:45:46 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id F09065AFDFA; Mon, 13 May 2013 10:45:46 -0400 (EDT) From: David Taylor To: gcc@gcc.gnu.org, gdb@sourceware.org, binutils@soureware.org Subject: stabs changes for 64 bit targets Date: Mon, 13 May 2013 14:46:00 -0000 Message-ID: <18975.1368456346@usendtaylorx2l> X-EMM-MHVC: 1 X-SW-Source: 2013-05/txt/msg00053.txt.bz2 Content-length: 2449 There are problems when using current STABS debug format for 64 bit targets. A STABS entry is 12 bytes: . e_strx (4 bytes) . e_type (1 byte) . e_other (1 byte) . e_desc (2 bytes) . e_value (4 bytes) Unless you have an awfully lot of debug information, 4 bytes for a string table index is fine. But, for 64 bit targets, 4 bytes for an address is not so good. Initially we were using the x86-64 small memory model. But we now have a need to place some data symbols at higher addresses. Doing so and compiling with debugging turned on causes linkage problems -- with STABS relocations. So, we are now looking at 16 byte STABS entries -- increasing the size of the e_value field from 4 bytes to 8 bytes and leaving the other 4 fields alone. We want things to be backwards compatible and to have one tool chain that is caplable of producing / consuming both formats. We also want the changes to be implemented in such a way that they would be considered for inclusion in future versions of GCC, BINUTILS, and GDB. To that end, our thinking is that: . GCC would still produce STABS entries as now; but, would also support a command line switch to tell the assembler that the larger STABS were wanted. . the new section would be named .stab2 instead of .stab [I wasn't sure what to name it; I didn't want to call it .stab64 as I could envision someone someday needing to increase the size of the string table. I don't really care what it is called provided it is not .stab (backwards compatibility).] . if both .stab and .stab2 are present in an executable, they would share the same string table (unless this proves to be a problem, in which case the .stab2 string table would be named either .stab2str or .stabstr2) . GAS, based on a command line switch would produce either 12 byte or 16 byte STABS. . OBJDUMP / LD / GDB would look at the section name to determine how to read the STABS. I am told that the GCC and BINUTILS changes are done except for the addition of new tests to the testsuite. The GDB changes have been started. Does this sound like a reasonable approach? Is the new section name okay? Or do people have suggestions for a better name? Anything left out that needs to be done for the changes to be considered for inclusion? EMC has paperwork on file for copyright assignment of past and future changes to GCC, BINUTILS, and GDB. David -- David Taylor dtaylor@emc.com