[RFC] cygwin GDB "long long" return value error

[RFC] cygwin GDB "long long" return value error

[Pierre Muller]

  The return value of a long long functions
in value_being_returned (called in finish command)
relies on the EXTRACT_RETURN_VALUE macro.

  This macro has a correct implementation in config/i386/tm-i386.h
where 64bit integers are taken from the edx:eax pair.

  But config/i386/tm-i386v.h overwrites this macro
by using memcpy on the register buffer, which then leads to
using ecx:eax as return value.

  As cygwin version relies on tm-i386v.h,
the 64bit integers are wrong.

  Do really some targets use ecx:eax, or is it just that
64bit was not considered at the time this macro was written?

  Anyhow STORE_RETURN_VALUE in config/i386/tm-i386.h
suffers from the same error, the "long long" value will be copied
into ecx:eax instead of edx:eax


  Simple test program :


long long
getval ()
{
  return 0x030000524f;
}

int
main ()
{
  long long i = getval ();
  return 0;
}

Just put a break inside getval function
and use 'finish' or 'return 0x300000000'
to test if rading and writing works correctly.

  The display of the return value might be 
correct as it depends on the value contained in the ecx register.

  Several other i386 targets seem to include tm-i386v.h
or use other function that also don't handle 64 bit 
return value correctly (unless these targets use ecx:eax).

  

Re: [RFC] cygwin GDB "long long" return value error

[Mark Kettenis]

Pierre Muller <pierre@idefix.wisa.be> writes:

>   This macro has a correct implementation in config/i386/tm-i386.h
> where 64bit integers are taken from the edx:eax pair.

Nowadays it's a function in i386-tdep.c.

>   But config/i386/tm-i386v.h overwrites this macro
> by using memcpy on the register buffer, which then leads to
> using ecx:eax as return value.

Yep.  I don't know what the origional System V compiler did, but it's
unlikely that it did return 64-bit quantities in ecx:eax, if it
supported 64-bit quantities at all.  I have a patch that removes most
of the presumably unecessary junk from tm-i386v.h.  I might as well
post it.

>   As cygwin version relies on tm-i386v.h,
> the 64bit integers are wrong.

IMHO cygwin shouldn't include tm-i386v.h.  tm-i386.h already the
necessary stuff, and really does a better job at it.  Cygwin
defenitely isn't derived from System V.

>   Anyhow STORE_RETURN_VALUE in config/i386/tm-i386.h
> suffers from the same error, the "long long" value will be copied
> into ecx:eax instead of edx:eax

Fixed in the current sources (both mainline and the 5.1 branch) :-).

Thanks for the report anyway,

Mark

[RFC/RFA] fix cygwin GDB "long long" return value error

[Pierre Muller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]

  This RFC/RFA is the followup of the thread about
that I started with the folliwng subject:

  [RFC] cygwin GDB "long long" return value error

At 21:07 04/10/01 , Mark Kettenis a écrit:
>Pierre Muller <pierre@idefix.wisa.be> writes:
>
> >   This macro has a correct implementation in config/i386/tm-i386.h
> > where 64bit integers are taken from the edx:eax pair.
>
>Nowadays it's a function in i386-tdep.c.
>
> >   But config/i386/tm-i386v.h overwrites this macro
> > by using memcpy on the register buffer, which then leads to
> > using ecx:eax as return value.
>
>Yep.  I don't know what the origional System V compiler did, but it's
>unlikely that it did return 64-bit quantities in ecx:eax, if it
>supported 64-bit quantities at all.  I have a patch that removes most
>of the presumably unecessary junk from tm-i386v.h.  I might as well
>post it.
>
> >   As cygwin version relies on tm-i386v.h,
> > the 64bit integers are wrong.
>
>IMHO cygwin shouldn't include tm-i386v.h.  tm-i386.h already the
>necessary stuff, and really does a better job at it.  Cygwin
>defenitely isn't derived from System V.

Yes, but I tried to change tm-i386v.h into tm-i386.h
it comiples OK and fixes trhe long klong errors that I reported first;
but I have no idea if it does make other good or bad changes.
It is probably necessary to run the testsuite before and after applying 
this patch, but
I can't do that on my machine.

ChangeLog:

2001-10-05 Pierre Muller <muller@ics.u-strasbg.fr>

         * config/i386/tm-cygwin.h: include tm-i386.h instead of tm-i386v.h.
              This fixes errors in "long long" handling for 'finish' and 
'return' commands.

Index: config/i386/tm-cygwin.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-cygwin.h,v
retrieving revision 1.8
diff -r1.8 tm-cygwin.h
26c26
< #include "i386/tm-i386v.h"
---
 > #include "i386/tm-i386.h"

> >   Anyhow STORE_RETURN_VALUE in config/i386/tm-i386.h
> > suffers from the same error, the "long long" value will be copied
> > into ecx:eax instead of edx:eax
>
>Fixed in the current sources (both mainline and the 5.1 branch) :-).

   Yes, I saw it now and it does indeed work OK for go32v2 target.
(My latest go32v2 build was older ..)

Could someone, (Christopher ?) explains us why
tm-cygwin.h includes tm-i386v.h when as Mark Kettenis said,
Cygwin is not derived from System V ?



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [RFC/RFA] fix cygwin GDB "long long" return value error

[Christopher Faylor]

On Fri, Oct 05, 2001 at 12:00:09PM +0200, Pierre Muller wrote:
>Could someone, (Christopher ?) explains us why tm-cygwin.h includes
>tm-i386v.h when as Mark Kettenis said, Cygwin is not derived from
>System V ?

I am sorry but I really can't explain why tm-cygwin.h includes
tm-i386v.h.  I believe that predates my maintainership.

However, if you have tested your patch and everything works fine,
please check it in.  I've verified that gdb seems to work ok
but I haven't run it through the test suite.

cgf

Re: [RFC/RFA] fix cygwin GDB "long long" return value error

[Stan Shebs]

Christopher Faylor wrote:
> 
> On Fri, Oct 05, 2001 at 12:00:09PM +0200, Pierre Muller wrote:
> >Could someone, (Christopher ?) explains us why tm-cygwin.h includes
> >tm-i386v.h when as Mark Kettenis said, Cygwin is not derived from
> >System V ?
> 
> I am sorry but I really can't explain why tm-cygwin.h includes
> tm-i386v.h.  I believe that predates my maintainership.

Probably because Windows uses COFF, as does SVR3, so in a very loose
sense, Cygwin does have an ancestral relationship with SVR3.
Ironically, it doesn't look like there are any actual vestiges of
COFFness left in tm-i386v.h

Stan

Re: [RFC/RFA] fix cygwin GDB "long long" return value error

[Christopher Faylor]

On Wed, Oct 10, 2001 at 10:10:23PM -0400, Christopher Faylor wrote:
>On Fri, Oct 05, 2001 at 12:00:09PM +0200, Pierre Muller wrote:
>>Could someone, (Christopher ?) explains us why tm-cygwin.h includes
>>tm-i386v.h when as Mark Kettenis said, Cygwin is not derived from
>>System V ?
>
>I am sorry but I really can't explain why tm-cygwin.h includes
>tm-i386v.h.  I believe that predates my maintainership.
>
>However, if you have tested your patch and everything works fine,
>please check it in.  I've verified that gdb seems to work ok
>but I haven't run it through the test suite.

Nevermind.  I just checked this in.

Thanks,
cgf