From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-72063-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 3690 invoked by alias); 12 Apr 2010 18:50:58 -0000
Received: (qmail 3681 invoked by uid 22791); 12 Apr 2010 18:50:57 -0000
X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 	tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45
X-Spam-Check-By: sourceware.org
Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Apr 2010 18:50:49 +0000
Received: by vws14 with SMTP id 14so324549vws.0         for <gdb-patches@sourceware.org>; Mon, 12 Apr 2010 11:50:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.44.198 with HTTP; Mon, 12 Apr 2010 11:50:47 -0700 (PDT)
In-Reply-To: <201004121823.o3CINtrD023513@glazunov.sibelius.xs4all.nl>
References: <20100410221943.GA9675@intel.com> <20100410222742.GA9901@intel.com> 	 <20100411000053.GA12675@intel.com> <20100411205250.GA24158@intel.com> 	 <20100412132225.GA5932@intel.com> 	 <201004121823.o3CINtrD023513@glazunov.sibelius.xs4all.nl>
Date: Mon, 12 Apr 2010 18:50:00 -0000
Received: by 10.220.126.140 with SMTP id c12mr2225995vcs.170.1271098247103;  	Mon, 12 Apr 2010 11:50:47 -0700 (PDT)
Message-ID: <m2s6dc9ffc81004121150pe337b27fx39dde43ad7593d97@mail.gmail.com>
Subject: Re: PATCH: PR corefiles/11467: amd64 gdb generates corrupted 32bit  	core file
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2010-04/txt/msg00382.txt.bz2

On Mon, Apr 12, 2010 at 11:23 AM, Mark Kettenis <mark.kettenis@xs4all.nl> w=
rote:
>> Date: Mon, 12 Apr 2010 06:22:25 -0700
>> From: "H.J. Lu" <hongjiu.lu@intel.com>
>>
>> On Sun, Apr 11, 2010 at 01:52:50PM -0700, H.J. Lu wrote:
>> > Hi,
>> >
>> > Thanks for Mark's pointer. Solution is very simple. We just need to
>> > make sure that we call the right fill_gregset for 32bit executable
>> > on both Linux/x86-64 and Linux/i386. =A0OK to install?
>> >
>> > Thanks.
>> >
>> >
>>
>> Small update to use tdep->gregset_reg_offset instead of
>> i386_linux_gregset_reg_offset. =A0OK to install?
>
> No. =A0Like I explained in an earlier mail, we're not supposed to end up
> in fetch_gregset() in the first place.
>

fetch_gregset is always defined and used to fill .reg section in
coredump on Linux/x86. i386-tdep.c has

const struct regset *
i386_regset_from_core_section (struct gdbarch *gdbarch,
                               const char *sect_name, size_t sect_size)
{
  struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch);

  if (strcmp (sect_name, ".reg") =3D=3D 0 && sect_size =3D=3D tdep->sizeof_=
gregset)
    {
      if (tdep->gregset =3D=3D NULL)
        tdep->gregset =3D regset_alloc (gdbarch, i386_supply_gregset,
                                      i386_collect_gregset);
      return tdep->gregset;
    }

For Linux,  tdep->sizeof_gregset !=3D the size of .reg section. In fact,
they have nothing to do with each other. sizeof_gregset includes
SSE and AVX registers, which have offset =3D=3D -1 since they aren't
general-purpose registers. I don't believe we should set tdep->gregset
since general-purpose registers is a special case for Linux/x86. They
are handled differently. I don't want to change it.

Please see i386-linux-nat.c for all the details.

Thanks.


--=20
H.J.