This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch/rfc] gdb: clean up x86 cpuid implementations
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 07 May 2013 05:41:36 +0300
- Subject: Re: [patch/rfc] gdb: clean up x86 cpuid implementations
- References: <201305061451 dot 24861 dot vapier at gentoo dot org> <831u9jgagk dot fsf at gnu dot org> <201305061630 dot 27822 dot vapier at gentoo dot org>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Mike Frysinger <vapier@gentoo.org>
> Date: Mon, 6 May 2013 16:30:26 -0400
> Cc: gdb-patches@sourceware.org
>
> > The current code in go32-nat.c was tested to work in all the
> > environments supported by that target, without GPFaulting or
> > triggering any other disasters. I don't think we have the resources
> > to repeat all that testing with the new code, which tries to detect
> > newer CPUs, and so could trigger SIGILL. So I'd like to leave
> > go32-nat.c alone, if possible.
>
> on the flip side, if the new common header was tested, go32-nat (and any other
> DOS like target) wouldn't have to do anymore work, and would be easy to use
> cpuid in more places.
That's in theory. In practice, go32 (a.k.a. DJGPP) needs a DPMI
server to be able to run 32-bit protected-mode code on top of a 16-bit
real-mode OS. The DPMI environment has its own peculiar rules about
what can and cannot be done, and more importantly, different DPMI
providers bend those rules in different directions. The net result is
that not everything that works for any other 386 out there will
necessarily work in the DPMI environment.
> but in the end, i don't care about dead things like DOS, so if people prefer
> to leave the cruft in that one file, i can look the other way while still
> cleaning up everything else.
Yes, please.
Thanks.