From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11370 invoked by alias); 20 Feb 2004 18:56:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11354 invoked from network); 20 Feb 2004 18:56:28 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 20 Feb 2004 18:56:28 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 239B42B92; Fri, 20 Feb 2004 13:56:27 -0500 (EST) Message-ID: <4036585A.8010805@gnu.org> Date: Fri, 20 Feb 2004 18:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Ulrich Weigand Cc: gdb@sources.redhat.com Subject: Re: 32-bit gcore on amd64 References: <200402192347.AAA20515@faui1d.informatik.uni-erlangen.de> In-Reply-To: <200402192347.AAA20515@faui1d.informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00294.txt.bz2 >>>This function totally assumes that it's creating a 64-bit note section. >>>How does BFD figure out that it should instead use 32-bit note code? > > > It doesn't, as far as I can see. Ah, "good", at least I wasn't missing anything. >>>As a somewhat amazing PS: bigcore.exp does pass 32-bit mode on >>>AMD-64 ->> the 32-bit read path is ok. > > > That's because there are tons of special-cased code pieces in > the *read* path to handle this; check for HAVE_PRPSINFO32_T > and HAVE_PRSTATUS32_T in bfd/elf.c. (This relies on sys/procfs.h > to provide both 32-bit and 64-bit versions -- reading cores > didn't work initially on s390x because those were missing.) > > Such special cases are completely absent from the write path, > however. > > (The other question is whether these 32-on-64 special cases are > really the right way to solve the problem -- a generic solution > should preferably solve the any-on-any cross-gdb core dump > access problem ...) That's why I'm thinking that: > #4 0x00000000004583f8 in linux_make_note_section (obfd=0x87fc90, > note_size=0x7fbfffed8c) at /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:302 > > Here, I'm thinking that if this is to be portable, this would have to be an architecture method (also parameterized with the target). belongs in the architecture vector. Andrew