Re: [RFC] Fix for Go32-v2 native woes

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Tue, 6 Apr 2010 16:15:05 +0200
> 
>   I finally managed to find a fix, but it is not straightforward:
>   I had to add a new xml file in features/i386 directory
> specific for go32v2 target, that does not read i386-sse.xml.
>   I had to adapt the code in i386-tdep.c to support
> missing feature_vector and to set tdesc to
> tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
> osabi was detected.
> 
>   This allows me to use CVS GDB on DJGPP again.
> 
>   I checked with a testsuite run on gcc-farm that nothing changed
> for at least that other target (amd64-linux).
> 
>   Similar fixes might be required for other 'old'
> i386 targets that do not support SSE registers.
> 
>   Comments welcome as usual!

Thanks.  But I really hope that a much more elegant solution could be
found.  A general layer of code such as i386-tdep.c should not include
any code that is specific to certain targets.

Why do we always read i386-sse.xml or assume that SSE is supported?
We should not assume any CPU features by default if there are CPUs out
there which we support that don't have them.

Re: Go32-v2 native woes

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Tue, 6 Apr 2010 01:29:22 +0200
> 
> top> p num_regs
> $1 = 32
> top> p *data.arch_regs
> $2 = {num = 33, alloc = 36, vec = {{reg = 0x3ed6d8, type = 0x0}}}
> top>
> 
>   The additional reg in arch_regs seems to come from
> i386_validate_tdesc_p function:
>  /* Need to include %mxcsr, so add one.  */
>    num_regs += tdep->num_xmm_regs + 1;
> 
> Adding this condition 
> if (tdep->num_xmm_regs)
> removes the problem above,

Thanks.  I'm okay with this change, but please wait for Mark to
comment on it.

Re: [RFC] Fix for Go32-v2 native woes

[Mark Kettenis]

> Date: Tue, 06 Apr 2010 20:45:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Date: Tue, 6 Apr 2010 16:15:05 +0200
> > 
> >   I finally managed to find a fix, but it is not straightforward:
> >   I had to add a new xml file in features/i386 directory
> > specific for go32v2 target, that does not read i386-sse.xml.
> >   I had to adapt the code in i386-tdep.c to support
> > missing feature_vector and to set tdesc to
> > tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
> > osabi was detected.
> > 
> >   This allows me to use CVS GDB on DJGPP again.
> > 
> >   I checked with a testsuite run on gcc-farm that nothing changed
> > for at least that other target (amd64-linux).
> > 
> >   Similar fixes might be required for other 'old'
> > i386 targets that do not support SSE registers.
> > 
> >   Comments welcome as usual!
> 
> Thanks.  But I really hope that a much more elegant solution could be
> found.  A general layer of code such as i386-tdep.c should not include
> any code that is specific to certain targets.
> 
> Why do we always read i386-sse.xml or assume that SSE is supported?
> We should not assume any CPU features by default if there are CPUs out
> there which we support that don't have them.

Because that basically was the situation before.  When SSE support was
addid we didn't really have a way to detect whether a target supported
SSE or not.

Does Go32 really have no support for the SSE registers?

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Tue, 06 Apr 2010 20:45:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Date: Tue, 6 Apr 2010 16:15:05 +0200
> > 
> >   I finally managed to find a fix, but it is not straightforward:
> >   I had to add a new xml file in features/i386 directory
> > specific for go32v2 target, that does not read i386-sse.xml.
> >   I had to adapt the code in i386-tdep.c to support
> > missing feature_vector and to set tdesc to
> > tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
> > osabi was detected.
> > 
> >   This allows me to use CVS GDB on DJGPP again.
> > 
> >   I checked with a testsuite run on gcc-farm that nothing changed
> > for at least that other target (amd64-linux).
> > 
> >   Similar fixes might be required for other 'old'
> > i386 targets that do not support SSE registers.
> > 
> >   Comments welcome as usual!
> 
> Thanks.  But I really hope that a much more elegant solution could be
> found.  A general layer of code such as i386-tdep.c should not include
> any code that is specific to certain targets.

Btw, I think this solution cannot be acceptable for one more reason:
GDB should work even without libexpat linked in, and then XML files
cannot be read.

Can you see what happens with this problem in a GDB build without
libexpat?  (Sorry, I won't be able to do that myself in the near
future.)

TIA

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Tue, 6 Apr 2010 20:41:01 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org
> 
> > Why do we always read i386-sse.xml or assume that SSE is supported?
> > We should not assume any CPU features by default if there are CPUs out
> > there which we support that don't have them.
> 
> Because that basically was the situation before.

I'm not sure I follow.  GDB 7 builds and works in the DJGPP port
without any trouble, even though SSE support was there before, wasn't
it?

> When SSE support was addid we didn't really have a way to detect
> whether a target supported SSE or not.

Well, then it should be part of the target configuration.

> Does Go32 really have no support for the SSE registers?

Yes, really.  The debug interface provided by DPMI (the interface for
running protected-mode programs on DOS, which is a real-mode OS) does
not support SSE.  And since no one is developing the DPMI spec or DPMI
ser5vices these days, SSE will never be supported by DJGPP.  In fact,
none of the special registers of the modern x86 CPUs (XMM etc.) will
ever be supported.

Therefore, the fact that SSE is not supported by DJGPP can be
established at compile time.

Re: [RFC] Fix for Go32-v2 native woes

[H.J. Lu]

On Tue, Apr 6, 2010 at 8:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 06 Apr 2010 20:45:25 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: gdb-patches@sourceware.org
>>
>> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
>> > Date: Tue, 6 Apr 2010 16:15:05 +0200
>> >
>> >   I finally managed to find a fix, but it is not straightforward:
>> >   I had to add a new xml file in features/i386 directory
>> > specific for go32v2 target, that does not read i386-sse.xml.
>> >   I had to adapt the code in i386-tdep.c to support
>> > missing feature_vector and to set tdesc to
>> > tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
>> > osabi was detected.
>> >
>> >   This allows me to use CVS GDB on DJGPP again.
>> >
>> >   I checked with a testsuite run on gcc-farm that nothing changed
>> > for at least that other target (amd64-linux).
>> >
>> >   Similar fixes might be required for other 'old'
>> > i386 targets that do not support SSE registers.
>> >
>> >   Comments welcome as usual!
>>
>> Thanks.  But I really hope that a much more elegant solution could be
>> found.  A general layer of code such as i386-tdep.c should not include
>> any code that is specific to certain targets.
>
> Btw, I think this solution cannot be acceptable for one more reason:
> GDB should work even without libexpat linked in, and then XML files
> cannot be read.
>
> Can you see what happens with this problem in a GDB build without
> libexpat?  (Sorry, I won't be able to do that myself in the near
> future.)
>

I have a followup patch on top of AVX gdb to support i386 without
SSE. I will submit it after AVX patches are checked in.


-- 
H.J.

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Tue, 6 Apr 2010 23:19:36 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Cc: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org
> 
> I have a followup patch on top of AVX gdb to support i386 without
> SSE. I will submit it after AVX patches are checked in.

Thank you.

Btw, what happens with the register-related features you added if
libexpat is not linked in?  Do these features silently disappear
(good) or break the build (bad) or cause fatal internal errors at run
time (worse)?

TIA

Re: [RFC] Fix for Go32-v2 native woes

[Daniel Jacobowitz]

On Wed, Apr 07, 2010 at 02:44:10AM -0400, Eli Zaretskii wrote:
> > Date: Tue, 6 Apr 2010 23:19:36 -0700
> > From: "H.J. Lu" <hjl.tools@gmail.com>
> > Cc: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org
> > 
> > I have a followup patch on top of AVX gdb to support i386 without
> > SSE. I will submit it after AVX patches are checked in.
> 
> Thank you.
> 
> Btw, what happens with the register-related features you added if
> libexpat is not linked in?  Do these features silently disappear
> (good) or break the build (bad) or cause fatal internal errors at run
> time (worse)?

They continue to work (even better).  We parse the XML files used for
native debugging into C files, and the generated C files are stored in
the source tree.  This was a design requirement before we could
require XML descriptions for any native platform.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Wed, 7 Apr 2010 10:41:37 -0400
> From: Daniel Jacobowitz <dan@codesourcery.com>
> Cc: "H.J. Lu" <hjl.tools@gmail.com>, pierre.muller@ics-cnrs.unistra.fr,
> 	gdb-patches@sourceware.org
> 
> > Btw, what happens with the register-related features you added if
> > libexpat is not linked in?  Do these features silently disappear
> > (good) or break the build (bad) or cause fatal internal errors at run
> > time (worse)?
> 
> They continue to work (even better).  We parse the XML files used for
> native debugging into C files, and the generated C files are stored in
> the source tree.  This was a design requirement before we could
> require XML descriptions for any native platform.

Thanks.  So this means we currently assume SSE support regardless of
the XML files, is that right?

Re: [RFC] Fix for Go32-v2 native woes

[H.J. Lu]

On Wed, Apr 7, 2010 at 10:33 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 7 Apr 2010 10:41:37 -0400
>> From: Daniel Jacobowitz <dan@codesourcery.com>
>> Cc: "H.J. Lu" <hjl.tools@gmail.com>, pierre.muller@ics-cnrs.unistra.fr,
>>       gdb-patches@sourceware.org
>>
>> > Btw, what happens with the register-related features you added if
>> > libexpat is not linked in?  Do these features silently disappear
>> > (good) or break the build (bad) or cause fatal internal errors at run
>> > time (worse)?
>>
>> They continue to work (even better).  We parse the XML files used for
>> native debugging into C files, and the generated C files are stored in
>> the source tree.  This was a design requirement before we could
>> require XML descriptions for any native platform.
>
> Thanks.  So this means we currently assume SSE support regardless of
> the XML files, is that right?

It should be fixed on hjl/mmx branch at

http://git.kernel.org/?p=devel/gdb/hjl/avx.git;a=summary



-- 
H.J.