This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] Query Red Boot's i386 CPU id
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Mark Kettenis <kettenis at chello dot nl>
- Cc: Eli Zaretskii <eliz at is dot elta dot co dot il>,Andrew Cagney <ac131313 at ges dot redhat dot com>,gdb-patches at sources dot redhat dot com
- Date: Thu, 29 Aug 2002 19:38:28 -0400
- Subject: Re: [rfc] Query Red Boot's i386 CPU id
- References: <Pine.SUN.3.91.1020829080855.26003D-100000@is> <86bs7lp92j.fsf@elgar.kettenis.dyndns.org>
On Fri, Aug 30, 2002 at 12:57:24AM +0200, Mark Kettenis wrote:
> I haven't looked at the patch too closely yet but:
>
> Eli Zaretskii <eliz@is.elta.co.il> writes:
>
> > > - a command to query the cpuid (info cpu).
> > >
> > > The actual CPU information is determined using a small file database
> > > (installed in ..../share/gdb/i386-cpuid).
> > >
> > > Comments on how this was implemented, and what, if anything, could be
> > > integrated into GDB, welcome.
> >
> > A few comments:
> >
> > (1) Why is this feature implemented for remote targets only? Why is
> > the database of CPU ids installed only for embedded builds?
>
> Seconded. I'm getting wild ideas of downloading the cpuid code to the
> target, executing it there, and fetching the return value, and use
> that to e.g. select whether it makes sense to do MMX or SSE :-).
[Makes me a little nervous to randomly execute code on the target...
have you ever accidentally (or deliberately!) connected the wrong arch
gdb?]
I'm against the separate database file however. Can we generate a C
table from it, the way we do other data?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer