From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-17307-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 2518 invoked by alias); 19 Feb 2004 23:12:27 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 2481 invoked from network); 19 Feb 2004 23:12:25 -0000
Received: from unknown (HELO localhost.redhat.com) (216.129.200.20)
  by sources.redhat.com with SMTP; 19 Feb 2004 23:12:25 -0000
Received: from gnu.org (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 6B6A42B92; Thu, 19 Feb 2004 18:12:22 -0500 (EST)
Message-ID: <403542D6.2070603@gnu.org>
Date: Thu, 19 Feb 2004 23:12:00 -0000
From: Andrew Cagney <cagney@gnu.org>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217
MIME-Version: 1.0
To: gdb@sources.redhat.com
Subject: 32-bit gcore on amd64
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-02/txt/msg00259.txt.bz2

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.

Here's the first backtrace:

#0  amd64_collect_native_gregset (regcache=0x808410, gregs=0x7fbfffead0,
     regnum=-1) at /home/cygnus/cagney/GDB/src/gdb/amd64-nat.c:124
#1  0x0000000000450e16 in fill_gregset (gregsetp=0x808410, 
regnum=-1073747248)
     at /home/cygnus/cagney/GDB/src/gdb/x86-64-linux-nat.c:126
#2  0x000000000045803d in linux_do_thread_registers (obfd=0x87fc90, ptid=
       {pid = 10494, lwp = 10494, tid = 0}, note_data=0x8b0960 "\005",
     note_size=0x7fbfffed8c) at 
/home/cygnus/cagney/GDB/src/gdb/linux-proc.c:180

This function is asking fill_gregset to populate an amd64 gregset_t.  I 
think it should be asking for the 32-bit gregset_t to be filled in.

#3  0x0000000000458227 in linux_do_registers (obfd=0x87fc90, ptid=
       {pid = 10494, lwp = 0, tid = 0}, note_data=0x8b0960 "\005",
     note_size=0x7fbfffed8c) at 
/home/cygnus/cagney/GDB/src/gdb/linux-proc.c:250
#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).

#5  0x00000000004594d2 in gcore_command (args=0x0, from_tty=-1073747248)
     at /home/cygnus/cagney/GDB/src/gdb/gcore.c:80

Now the second backtrace:

#0  elfcore_write_prstatus (abfd=0x87fc90, buf=0x8b0960 "\005",
     bufsiz=0x7fbfffed8c, pid=10494, cursig=5, gregs=0x7fbfffead0)
     at /home/cygnus/cagney/GDB/src/bfd/elf.c:7163

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?

#1  0x0000000000458058 in linux_do_thread_registers (obfd=0x87fc90, ptid=
       {pid = 10494, lwp = 10494, tid = 0}, note_data=0x8b0960 "\005",
     note_size=0x7fbfffed8c) at 
/home/cygnus/cagney/GDB/src/gdb/linux-proc.c:181
#2  0x0000000000458227 in linux_do_registers (obfd=0x87fc90, ptid=
       {pid = 10494, lwp = 0, tid = 0}, note_data=0x8b0960 "\005",
     note_size=0x7fbfffed8c) at 
/home/cygnus/cagney/GDB/src/gdb/linux-proc.c:250
#3  0x00000000004583f8 in linux_make_note_section (obfd=0x87fc90,
     note_size=0x7fbfffed8c) at 
/home/cygnus/cagney/GDB/src/gdb/linux-proc.c:302
#4  0x00000000004594d2 in gcore_command (args=0x0, from_tty=-1073747032)
     at /home/cygnus/cagney/GDB/src/gdb/gcore.c:80

Andrew

As a somewhat amazing PS: bigcore.exp does pass 32-bit mode on AMD-64 
->> the 32-bit read path is ok.