From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-29110-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 20714 invoked by alias); 4 Dec 2003 21:18:08 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 20702 invoked from network); 4 Dec 2003 21:18:08 -0000
Received: from unknown (HELO zenia.home) (12.223.225.216)
  by sources.redhat.com with SMTP; 4 Dec 2003 21:18:08 -0000
Received: by zenia.home (Postfix, from userid 5433)
	id D5A5720766; Thu,  4 Dec 2003 16:16:32 -0500 (EST)
To: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
Cc: gdb-patches@sources.redhat.com, uweigand@de.ibm.com
Subject: Re: [PATCH] S/390 port modernization 1/4
References: <200312042006.VAA07701@faui1d.informatik.uni-erlangen.de>
From: Jim Blandy <jimb@redhat.com>
Date: Thu, 04 Dec 2003 21:18:00 -0000
In-Reply-To: <200312042006.VAA07701@faui1d.informatik.uni-erlangen.de>
Message-ID: <vt2vfowz3kf.fsf@zenia.home>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2003-12/txt/msg00139.txt.bz2


The rearrangement of the register code looks great.  I did core file
register handling in Not The Right Fashion, and your new code seems to
fix that.  And it's more legible.

It seems like s390-nat.c's s390_gregset_regmap and
s390_fpregset_regmap are essentially the same information as
s390-tdep.c's s390_regmap_gregset, s390x_regmap_gregset, and
s390_regmap_fpregset, except that the s390 / s390x distinction is
static in s390-nat.c, and dynamic in s390-tdep.c.  But if I recall
correctly, the way the types in the kernel header files work out, the
core dump format is always the same as the PTRACE uarea format.

Would it be possible to have s390-nat.c simply use the structures from
s390-tdep.c?  There's nothing wrong with having an s390-tdep.h file in
the gdb directory; that's the usual arrangement for native systems.

But this is a minor issue.  Given the nature of the IBM / FSF process,
feel free to either revise this patch, or submit it as a separate
patch, whichever is easiest for you.