i386-tdep.c:i386_extract_return_value()

i386-tdep.c:i386_extract_return_value()

[Mark Kettenis]

Hi All,

Right now, i386-tdep.c:i386_extract_return_value() is a mess.  I
wouldn't be surprised if the current implementation is incorrect for
all current supported targets, even for Linux.  There are two issues
here:

1) How are floating point values returned?  According to the GCC
   configuration files (gcc/config/i386.h) there are two
   possibilities: in st(0) or in the integer registers.  There might
   be a third possibility: in memory.  Most i386 targets return
   floating point values on the stack.  GDB however, only implements
   this for AIX and Linux.  That implementation is lossy right now,
   and probably only works correctly for a native GDB.  Returning in
   the integer registers might work for single precision numbers right
   now (I'm not sure), and maybe for double precision on Linux too
   (but that's obviously never used since Linux uses st(0)).  This
   probably means that all targets besides AIX and Linux lose right
   now.

2) How are integers longer than a word (4 bytes) returned?  Again
   according to GCC, most i386 targets return these in the integer
   registers (up to 12 bytes).  Linux implements this for integers up
   to 8 bytes (which is probably sufficient unless the same code would
   be used for returning extended precision floating point values).  A
   few (mostly SVR4 based systems) seem to return these values in
   memory.  I don't know if that's implemented correctly.  Again GDB
   doesn't handle things correctly for most targets.

How can we resolve this?  My suggestion for issue 1) is to add a new
macro that indicates if floats are returned on in st(0) (GCC
uses TARGET_FLOAT_RETURNS_IN_80387, would that be a good name to use
for GDB too?  Or should we drop the TARGET_ prefix?).  We can easily
do a little better in converting to the right virtual type than the
current code does.  Extended precision floating point numbers can
simply be copied, and for double precision an ISO C conforming
`double' should suffice.  We should probably turn this on for all
targets that use the new register layout and support the FPU
registers, and disable it again for those few targets that do not
return floating point values in st(0).

I think that issue 2) can be solved too.  I think that the code isn't
Linux specific at all.  AFAICS all i386 targets use the same registers
to return the values.  And those targets that do not return those
variables by value shouldn't call i386_extract_return_value() at all
(and if they do, they would lose anyway).

Comments?

Mark
From davidwilliams@ozemail.com.au Tue Dec 21 19:32:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: Breakpoints
Date: Tue, 21 Dec 1999 19:32:00 -0000
Message-id: <01BF4C88.F6D54B20.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00538.html
Content-length: 644

Hi all,

Does GDB ever need to set more than one breakpoint when stepping through 
source code? I have not (as yet) seen this type of behaviour.

I have a stub that supports breakpoints in flash via hardware facility but 
it can set only one breakpoint. If GDB requires more than one at time then 
I am in trouble. My target is 68EZ328 (68000 core, not CPU32, no BDM, has 
its own peculiar emulation mode). My stub currently looks for attempts to 
write trap #1 op-codes to program memory (FLASH) and then instead of 
writing to program memory it sets a hardware breakpoint at the address 
(thanks Stan for the suggestion).

TIA
David Williams
From kevinb@cygnus.com Tue Dec 21 19:54:00 1999
From: Kevin Buettner <kevinb@cygnus.com>
To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au>, "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: Re: Breakpoints
Date: Tue, 21 Dec 1999 19:54:00 -0000
Message-id: <991222035342.ZM17881@ocotillo.lan>
References: <01BF4C88.F6D54B20.davidwilliams@ozemail.com.au> <davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00539.html
Content-length: 463

On Dec 22,  2:29pm, David Williams wrote:

> Does GDB ever need to set more than one breakpoint when stepping through 
> source code? I have not (as yet) seen this type of behaviour.

Can the target do a singlestep in hardware or do you have to do
software emulation?  If the latter, when you're stepping by machine
instruction, you'd need two breakpoints on a conditional branch;
one for the branch target, the other for the instruction after the
branch.

Kevin
From davidwilliams@ozemail.com.au Tue Dec 21 20:00:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'Kevin Buettner'" <kevinb@cygnus.com>
Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: RE: Breakpoints
Date: Tue, 21 Dec 1999 20:00:00 -0000
Message-id: <01BF4C8C.E73B0340.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00540.html
Content-length: 946

Being a 68K core it can single step (at assembly level) using trace 
interrupt facility of the core. Ie the CPU hardware does the single 
stepping. I was more concerned  in the case when stepping at the source 
code level (c source in my case) that GDB may have to set more than one 
breakpoint.

Dave.

----------
From: 	Kevin Buettner[SMTP:kevinb@cygnus.com]
Sent: 	Wednesday, December 22, 1999 2:53 PM
To: 	davidwilliams@ozemail.com.au; 'gdb mail list'
Subject: 	Re: Breakpoints

On Dec 22,  2:29pm, David Williams wrote:

> Does GDB ever need to set more than one breakpoint when stepping through
> source code? I have not (as yet) seen this type of behaviour.

Can the target do a singlestep in hardware or do you have to do
software emulation?  If the latter, when you're stepping by machine
instruction, you'd need two breakpoints on a conditional branch;
one for the branch target, the other for the instruction after the
branch.

Kevin