From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: gdb@sourceware.cygnus.com Subject: i386-tdep.c:i386_extract_return_value() Date: Tue, 21 Dec 1999 07:49:00 -0000 Message-id: <199912211549.QAA00892@delius.kettenis.local> X-SW-Source: 1999-q4/msg00537.html 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 To: "'gdb mail list'" 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 To: "davidwilliams@ozemail.com.au" , "'gdb mail list'" 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> 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 To: "'Kevin Buettner'" Cc: "'gdb mail list'" 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