From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20265 invoked by alias); 13 Apr 2010 20:03:24 -0000 Received: (qmail 20186 invoked by uid 22791); 13 Apr 2010 20:03:23 -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; Tue, 13 Apr 2010 20:03:19 +0000 Received: by vws14 with SMTP id 14so976495vws.0 for ; Tue, 13 Apr 2010 13:03:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.44.198 with HTTP; Tue, 13 Apr 2010 13:03:17 -0700 (PDT) In-Reply-To: <201004131840.o3DIeDo9001302@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> <201004131840.o3DIeDo9001302@glazunov.sibelius.xs4all.nl> Date: Tue, 13 Apr 2010 20:03:00 -0000 Received: by 10.220.107.94 with SMTP id a30mr3361032vcp.135.1271188997241; Tue, 13 Apr 2010 13:03:17 -0700 (PDT) Message-ID: Subject: Re: PATCH: PR corefiles/11467: amd64 gdb generates corrupted 32bit core file From: "H.J. Lu" To: Mark Kettenis 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: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00422.txt.bz2 On Tue, Apr 13, 2010 at 11:40 AM, Mark Kettenis w= rote: > > Anyway, there is a somewhat fundamental flaw in > linux-nat.c:linux_nat_do_thread_registers() in that it always passes > the size of 64-bit version of gregset_t in the > gdbarch_regset_from_core_section() call. =A0That's wrong, and probably > the ultimate reason why the 64x32 gcore case isn't working properly. > That is problematic. For GP registers, total size of GP registers may not be the size of the note section of GP registers. So we can't use that section size. For x86, we can use size >=3D tdep->sizeof_gregset with a comment saying something like "size of 64bit version of gregset_t may be passed down." --=20 H.J.