Re: [GSoC2013] question about "improve the GDB port for GNU Hurd"

[Hacklu <hacklu.newborn@gmail.com>]

Hi.

在 2013-5-10，18:35，Thomas Schwinge <thomas@codesourcery.com> 写道：

> Hi!
> 
> 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.

> 
> On Thu, 2 May 2013 20:50:03 +0800, 陆岳 <hacklu.newborn@gmail.com> wrote:
>> On Thu, May 2, 2013 at 7:51 PM, Thomas Schwinge <thomas@codesourcery.com> wrote:
>> 
>>> 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.
>> 
>> I will do the compare after I have finished the application.
> 
> 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.
> 
> Oh, and if you want to read more about GDB's architecture and provenance,
> I can recommend Stan Shebs' chapter in »The Architecture of Open Source
> Applications«, <http://www.aosabook.org/en/gdb.html>.

That's just what I need. I am reading the <gdb internals> these days.
> 
> Grüße,
> Thomas


Yue Lu (陆岳)
From gdb-return-42126-listarch-gdb=sources.redhat.com@sourceware.org Mon May 13 14:46:03 2013
Return-Path: <gdb-return-42126-listarch-gdb=sources.redhat.com@sourceware.org>
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: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
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%6 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 <dtaylor@emc.com>
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