From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3156 invoked by alias); 19 Feb 2004 23:47:31 -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 3040 invoked from network); 19 Feb 2004 23:47:30 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 19 Feb 2004 23:47:30 -0000 Received: from faui1d.informatik.uni-erlangen.de (faui1d [131.188.31.34]) by faui10.informatik.uni-erlangen.de (8.9.3p3/8.1.9-FAU) with ESMTP id AAA01292; Fri, 20 Feb 2004 00:47:28 +0100 (CET) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id AAA20515; Fri, 20 Feb 2004 00:47:28 +0100 (CET) Message-Id: <200402192347.AAA20515@faui1d.informatik.uni-erlangen.de> Subject: Re: 32-bit gcore on amd64 To: cagney@gnu.org Date: Thu, 19 Feb 2004 23:47:00 -0000 Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00265.txt.bz2 Andrew Cagney wrote: >This is more questions than answers. I'm trying to figure out how GDB >should generate 32-bit core files on amd64 (i.e., get gmake check >'RUNTESTFLAGS=--target_board=unix/-m32 gcore.exp' to pass). >The problem is, everything I look at feels wrong. Yup, same problem on s390x. In fact, the gcore tests are the only failing tests when running the s390-on-s390x bi-arch test suite (in addition to those that fail on native s390, of course). [snip elfcore_write_prstatus] >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. >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 ...) Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de