Re: Debugging Windows Namespace extension dll

[cgf@cygnus.com (Chris Faylor)]

In article < l03130305b44c7ccd1ad2@[138.251.135.28] >,
Mark Hindley  <mh15@st-andrews.ac.uk> wrote:
>>The way that I normally do something like this is:
>
>>   gdb /windows/explorer.exe
>>   symbol-file MyDll.dll
>>    set args /root
>>    l DllMain
>>   bp <first line number in DllMain>
>>   run
>
>>As you probably, know using 'symbol-file' wipes out any existing symbol file
>>so this may not be exactly what you want.  You could use add-sym if you know
>>the load address of your DLL.
>
>>Hope this helps,
>>Chris Faylor
>
>
>Dear Chris,
>
>Thanks for your help.
>
>I still get Cannot access memory at 0x.... when I try to place a breakpoint
>at DllMain. I have managed to circumvent this by placing
>	if (bDebug) DebugBreak();
>
>in DllMain, but it is not pretty.

Note that I said that I set a breakpoint on the first line of the function.
That means that you have to first list the function, find the line and set
the breakpoint there.  You can't set a breakpoint on the function by saying
'bp DllMain' prior to running the program.

>And I still get an access violation every time the dll is loaded, either
>for the symbol table or for excution.

Do you get this when using the DebugBreak() method or does it always
occur?  Is the access violation occurring in gdb or in your program?

-chris
-- 
cgf@cygnus.com
http://www.cygnus.com/
From hjl@lucon.org Tue Nov 09 09:18:00 1999
From: hjl@lucon.org (H.J. Lu)
To: gdb@sourceware.cygnus.com (GDB)
Subject: Why does dejagnu use an old config.guess?
Date: Tue, 09 Nov 1999 09:18:00 -0000
Message-id: <19991109171805.5015B1B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00234.html
Content-length: 360

Hi,

There are 2 config.guess in dejagnu-19991108.tar.bz2:

#  find -name config.guess
./dejagnu/config.guess
./config.guess

./dejagnu/config.guess is older than ./config.guess. But it is the one
got installed. Any particular reason to do that? It is very annoying
since ./dejagnu/config.guess doesn't support the concurrent usage.

-- 
H.J. Lu (hjl@gnu.org)
From ac131313@cygnus.com Tue Nov 09 15:10:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: "H.J. Lu" <hjl@lucon.org>
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: Why does dejagnu use an old config.guess?
Date: Tue, 09 Nov 1999 15:10:00 -0000
Message-id: <3828A9BB.781B7068@cygnus.com>
References: <19991109171805.5015B1B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00235.html
Content-length: 633

"H.J. Lu" wrote:
> 
> Hi,
> 
> There are 2 config.guess in dejagnu-19991108.tar.bz2:
> 
> #  find -name config.guess
> ./dejagnu/config.guess
> ./config.guess
> 
> ./dejagnu/config.guess is older than ./config.guess. But it is the one
> got installed. Any particular reason to do that? It is very annoying
> since ./dejagnu/config.guess doesn't support the concurrent usage.

FYI, Dejagnu included with GDB is probably best described as being in
maintaner mode - I don't believe that any one is doing doing significant
work on that version.  Consequently the general aproach is ``if it ain't
broke, don't fix it''.

	enjoy,
		Andrew
From hjl@lucon.org Tue Nov 09 15:17:00 1999
From: hjl@lucon.org (H.J. Lu)
To: ac131313@cygnus.com (Andrew Cagney)
Cc: gdb@sourceware.cygnus.com
Subject: Re: Why does dejagnu use an old config.guess?
Date: Tue, 09 Nov 1999 15:17:00 -0000
Message-id: <19991109231718.7707E1B493@ocean.lucon.org>
References: <3828A9BB.781B7068@cygnus.com>
X-SW-Source: 1999-q4/msg00236.html
Content-length: 732

> 
> "H.J. Lu" wrote:
> > 
> > Hi,
> > 
> > There are 2 config.guess in dejagnu-19991108.tar.bz2:
> > 
> > #  find -name config.guess
> > ./dejagnu/config.guess
> > ./config.guess
> > 
> > ./dejagnu/config.guess is older than ./config.guess. But it is the one
> > got installed. Any particular reason to do that? It is very annoying
> > since ./dejagnu/config.guess doesn't support the concurrent usage.
> 
> FYI, Dejagnu included with GDB is probably best described as being in
> maintaner mode - I don't believe that any one is doing doing significant
> work on that version.  Consequently the general aproach is ``if it ain't
> broke, don't fix it''.
> 

It is broken. I have been fixing it for years.

-- 
H.J. Lu (hjl@gnu.org)
From shebs@cygnus.com Tue Nov 09 15:44:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: hjl@lucon.org
Cc: cagney@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Why does dejagnu use an old config.guess?
Date: Tue, 09 Nov 1999 15:44:00 -0000
Message-id: <199911092344.PAA27235@andros.cygnus.com>
References: <19991109231718.7707E1B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00237.html
Content-length: 1363

   Date: Tue, 9 Nov 1999 15:17:18 -0800 (PST)
   From: hjl@lucon.org (H.J. Lu)

   > "H.J. Lu" wrote:
   > > 
   > > Hi,
   > > 
   > > There are 2 config.guess in dejagnu-19991108.tar.bz2:
   > > 
   > > #  find -name config.guess
   > > ./dejagnu/config.guess
   > > ./config.guess
   > > 
   > > ./dejagnu/config.guess is older than ./config.guess. But it is the one
   > > got installed. Any particular reason to do that? It is very annoying
   > > since ./dejagnu/config.guess doesn't support the concurrent usage.
   > 
   > FYI, Dejagnu included with GDB is probably best described as being in
   > maintaner mode - I don't believe that any one is doing doing significant
   > work on that version.  Consequently the general aproach is ``if it ain't
   > broke, don't fix it''.

   It is broken. I have been fixing it for years.

Dejagnu is somewhat of an oddball in having its own config.guess.  Jason
has already committed a copy of the toplevel config.guess, along with the
comment that it should probably grab the top-level version, just as GCC
does now.

But Andrew is correct in that dejagnu is effectively unmaintained.  Rob
Savoye was intending to make a new release "soon", but that was nearly
a year ago.  Given that it's a critical tool for maintenance, I'd sure
like to see someone take it up again and do a new baseline release.

								Stan
From kettenis@wins.uva.nl Tue Nov 09 16:49:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: eliz@gnu.org, cgf@cygnus.com, jtc@redbacknetworks.com, jkj@sco.com, hjl@valinux.com, gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Tue, 09 Nov 1999 16:49:00 -0000
Message-id: <199911100048.BAA00256@delius.kettenis.local>
References: <199911090018.TAA12933@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00238.html
Content-length: 1886

   Date: Mon, 8 Nov 1999 19:18:11 -0500 (EST)
   From: Jim Blandy <jimb@cygnus.com>

   Are we settled on the essential contents of tm-i386.h?  Can we start
   removing the little [regs] and [fpregs] boxes from
   http://sourceware.cygnus.com/gdb/papers/linux/i386-includes.png ?

Maybe it would be a good idea to change the #defines of the register
numbers such that they match the names that GDB uses in its output,
i.e. FISEG_REGNUM instead of FCS_REGNUM, etc.

   Essentially, I see two outstanding questions remaining:

   - How should i386 targets handle the x86 FPU's 80-bit float type?  How
     can we make sure that hosts capable of handling it properly don't
     perform lossy conversions?

I still have a feeling that I don't understand the issues fully.  The
fact that the `free pascal compiler' uses 80-bit floats instead of
padded 96-bit floats complicates matters a bit.

   - What format should the output from "info float" take?  (Actually, it
     sounds like this is pretty much resolved.)

I have rewritten my implementation of "info float" to match the layout
I suggested last week.  I'll post a new patch next weekend, I have to
isolate the patch from some further changes I made, and want to test
it before submitting it.  Checking this in would give people a chance
at loooking at the layout, and any further changes to the layout can
be made without too much trouble.

   Notably missing from this list are any other questions about tm-i386.h
   as it stands.  Am I correct in thinking that the other x86 port
   maintainers think it's basically sane?

Yes.  For the Hurd the only things I have to define in tm-i386gnu.h
are Mach/Hurd specific.

   (Again, I'm excluding issues related to `long double'; I do expect
   folks to retain their own definitions for coping with that.)

I think we should try to unify those too, but that might be done later.

Mark
From toddpw@windriver.com Wed Nov 10 01:40:00 1999
From: Todd Whitesel <toddpw@windriver.com>
To: jimb@cygnus.com (Jim Blandy)
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: MMX: Messy Multimedia eXtensions
Date: Wed, 10 Nov 1999 01:40:00 -0000
Message-id: <199911100940.BAA14019@alabama.wrs.com>
References: <199911090706.CAA13120@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00239.html
Content-length: 684

> - Assign them register numbers separate from the FP stack registers'.
> - Assign them the same numbers as the FP stack registers, and treat them as
>   an alternative way of looking at the FP registers' mantissas.

Two quickies from the peanut gallery:

Mapping one register to two numbers is hazardous to any code that might
exist which saves/restores the register file by naively looping through
the register numbers.

Don't the Pentium 3 "SSE" extensions make FP+MMX registers become truly
distinct registers? I suppose you're taking it as a given that we already
know how to handle this case; just thought I should mention it anyway...

-- 
Todd Whitesel
toddpw @ windriver.com
From eliz@gnu.org Wed Nov 10 07:36:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: kettenis@wins.uva.nl, cgf@cygnus.com, jtc@redbacknetworks.com, jkj@sco.com, hjl@valinux.com, gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 07:36:00 -0000
Message-id: <199911101536.KAA04550@mescaline.gnu.org>
References: <199911090018.TAA12933@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00240.html
Content-length: 399

> If so, I encourage folks to start deleting stuff from their more
> specialized tm-*.h files, and using the definitions in tm-i386.h.

I'm going through tm-go32.h now, but I have one question.  tm-i386.h
has several definitions conditioned on symbols like HAVE_I387_REGS.
What is the appropriate place to define (or undefine) these?  Is it
tm-go32.h before it includes tm-i386.h or somewhere else?
From jimb@cygnus.com Wed Nov 10 10:06:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: MMX: Messy Multimedia eXtensions
Date: Wed, 10 Nov 1999 10:06:00 -0000
Message-id: <npln86b4rx.fsf@zwingli.cygnus.com>
References: <199911100940.BAA14019@alabama.wrs.com>
X-SW-Source: 1999-q4/msg00241.html
Content-length: 656

> Mapping one register to two numbers is hazardous to any code that might
> exist which saves/restores the register file by naively looping through
> the register numbers.

Right.  And in my quick survey, it looked like there were other
problems, too.  For example, what would write_register_bytes do?

> Don't the Pentium 3 "SSE" extensions make FP+MMX registers become truly
> distinct registers? I suppose you're taking it as a given that we already
> know how to handle this case; just thought I should mention it anyway...

The Streaming SIMD Extensions do add a new set of registers, but the
MMX registers remain mapped to the FP register mantissas.
From jimb@cygnus.com Wed Nov 10 10:08:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 10:08:00 -0000
Message-id: <npk8nqb4oz.fsf@zwingli.cygnus.com>
References: <199911090018.TAA12933@zwingli.cygnus.com> <199911101536.KAA04550@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00242.html
Content-length: 570

> > If so, I encourage folks to start deleting stuff from their more
> > specialized tm-*.h files, and using the definitions in tm-i386.h.
> 
> I'm going through tm-go32.h now, but I have one question.  tm-i386.h
> has several definitions conditioned on symbols like HAVE_I387_REGS.
> What is the appropriate place to define (or undefine) these?  Is it
> tm-go32.h before it includes tm-i386.h or somewhere else?

Yes, it was the intention that the more specific .h files, like
tm-go32.h, which know more about the particular machine being
debugged, would define those.
From jimb@cygnus.com Wed Nov 10 10:14:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 10:14:00 -0000
Message-id: <npiu3ab4dl.fsf@zwingli.cygnus.com>
References: <199911090018.TAA12933@zwingli.cygnus.com> <199911100048.BAA00256@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00243.html
Content-length: 1177

> Maybe it would be a good idea to change the #defines of the register
> numbers such that they match the names that GDB uses in its output,
> i.e. FISEG_REGNUM instead of FCS_REGNUM, etc.

Yeah, that was the original intent, but I forgot to change the CPP
symbol names when I renamed the registers.  Rats; I wish I'd noticed
this before Chris and Eli started adapting their tm-*.h files.  Let's
wait on this until folks have submitted changes for their ports, and
then I can make all the changes atomically with `M-x
tags-query-replace'.

>    Notably missing from this list are any other questions about tm-i386.h
>    as it stands.  Am I correct in thinking that the other x86 port
>    maintainers think it's basically sane?
> 
> Yes.  For the Hurd the only things I have to define in tm-i386gnu.h
> are Mach/Hurd specific.

Great.  Three down, three to go.  I'm waiting for JKJ, HJL, and JTC.

>    (Again, I'm excluding issues related to `long double'; I do expect
>    folks to retain their own definitions for coping with that.)
> 
> I think we should try to unify those too, but that might be done later.

Right --- these and the Pascal issues can be dealt with next.
From jtc@redback.com Wed Nov 10 10:49:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Jim Blandy <jimb@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, Eli Zaretskii <eliz@gnu.org>, Chris Faylor <cgf@cygnus.com>, "J. Kean Johnston" <jkj@sco.com>, "H. J. Lu" <hjl@valinux.com>, gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 10:49:00 -0000
Message-id: <5myac6qj3f.fsf@jtc.redbacknetworks.com>
References: <199911090018.TAA12933@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00244.html
Content-length: 1983

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
Jim> Are we settled on the essential contents of tm-i386.h?  

I think so.  

On the embedded side, we'll eventually need a mechanism to set the
processor type instead of using the HAVE_I387_REGS, etc. macros to
define the register set at compile time.  Also, an embedded target
may have need to get at the control and debug registers (cr0, cr2,
cr3, cr4, dr0-dr7) and the global, local, and interrupt descriptor 
table registers while these may not be available to user programs 
on other systems.

Jim> Essentially, I see two outstanding questions remaining:
Jim>
Jim> - How should i386 targets handle the x86 FPU's 80-bit float type?
Jim>   How can we make sure that hosts capable of handling it properly
Jim>   don't perform lossy conversions?

I may have mentioned this before, but I believe that in the longer
term we should move away from lossy conversions on all hosts, even
those without 80/96 bit FP support by integrating a software FP
engine/library (This might be useful for simulators as well, since
we'd be able to handle exceptional conditions, rounding flags, etc.
more precisely).  The library I'm familiar with is John Hauser's
SoftFloat:
    http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html

Jim> - What format should the output from "info float" take?
Jim>   (Actually, it sounds like this is pretty much resolved.)

I'm more or less happy with the results, but I have no strong feelings
either.  As long as users can write user defined functions to present
the registers values in whatever format they want/need, I'm satisfied.

Jim> Notably missing from this list are any other questions about
Jim> tm-i386.h as it stands.  Am I correct in thinking that the other
Jim> x86 port maintainers think it's basically sane?

I think there are unresolved issues with MMX, but since you've started
another thread on that topic, I'll address them there.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Wed Nov 10 11:12:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: MMX: Messy Multimedia eXtensions
Date: Wed, 10 Nov 1999 11:12:00 -0000
Message-id: <5mso2eqi09.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00245.html
Content-length: 1242

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
Jim> If you want to print SSE registers, you can:

Jim>     (gdb) p $xmm3
Jim>     $14 = {f = {-2.5, -2.482337, -2.464674, -2.44701076}}

Jim> You can print MMX registers, too, but it's messier, since GDB doesn't
Jim> know whether it's eight 8-bit values, four 16-bit values, et cetera:

Jim>     (gdb) p $mm2
Jim>     $1 = {v8qi = {f = "\001\000\001\000\001\000\001"}, v4hi = {f = {1,
Jim>       1, 1, 1}}, v2si = {f = {65537, 65537}}, uint64 = 281479271743489}

Jim> (Please ignore the fact that the eight 8-bit integers are printed as
Jim> characters.  I'm going to fix that.)

It appears that the registers are represented by a union or struct.
Can individual elements be used in GDB expressions?  If so, can you
show how to represent the least significant byte in a mmx register?
If not, I think this is a very serious deficiency.

There doesn't appear to be an entry in the MMX union for the single
precision FP values in AMD's 3DNow extensions.  Wearing my GNU hat,
(rather than my Cygnus-shareholder hat), I'd be very disapointed if
this got integrated into GDB without AMD 3DNow support even if Intel
funded Cygnus to do MMX work.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From khilman@equator.com Wed Nov 10 11:18:00 1999
From: Kevin Hilman <khilman@equator.com>
To: gdb@sourceware.cygnus.com
Subject: env variables in command files
Date: Wed, 10 Nov 1999 11:18:00 -0000
Message-id: <r27ljq9muz.fsf@bobdog.equator.com>
X-SW-Source: 1999-q4/msg00246.html
Content-length: 249

Is there a way to use env variables from gdb command files?

I can do a 'show env' but I can't figure out how to use the result.
It's not in the history.  Ideas?

(gdb) show env SHELL
SHELL = /bin/bash
(gdb) p $0
The history is empty.
(gdb) 

-kev-
From jimb@cygnus.com Wed Nov 10 12:14:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 12:14:00 -0000
Message-id: <np7ljqayuw.fsf@zwingli.cygnus.com>
References: <199911090018.TAA12933@zwingli.cygnus.com> <5myac6qj3f.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00247.html
Content-length: 2003

> Jim> Are we settled on the essential contents of tm-i386.h?  
> 
> I think so.  

Great.  So, which tm-*.h file do you guys actually use?  Which regset
can we delete?  My guess would be tm-i386v.h.  A lot of other tm.h
files #include that, but all but tm-vxworks.h and tm-i386sco5.h just
override them.

> On the embedded side, we'll eventually need a mechanism to set the
> processor type instead of using the HAVE_I387_REGS, etc. macros to
> define the register set at compile time.

Right --- and this is exactly what Andrew Cagney's gdbarch is for.
One of my next ambitions is to multi-arch the i386.

> Also, an embedded target may have need to get at the control and
> debug registers (cr0, cr2, cr3, cr4, dr0-dr7) and the global, local,
> and interrupt descriptor table registers while these may not be
> available to user programs on other systems.

That's a good point.  We can allocate spaces for those registers at
the end, I think, and have them be "" for specific targets that don't
have access to them.  GDB knows not to use those.  That's the way we
handle this on the MIPS.


> Jim> Essentially, I see two outstanding questions remaining:
> Jim>
> Jim> - How should i386 targets handle the x86 FPU's 80-bit float type?
> Jim>   How can we make sure that hosts capable of handling it properly
> Jim>   don't perform lossy conversions?
> 
> I may have mentioned this before, but I believe that in the longer
> term we should move away from lossy conversions on all hosts, even
> those without 80/96 bit FP support by integrating a software FP
> engine/library (This might be useful for simulators as well, since
> we'd be able to handle exceptional conditions, rounding flags, etc.
> more precisely).  The library I'm familiar with is John Hauser's
> SoftFloat:
>     http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html

I think everyone's in agreement on this.  And apparently the
simulators already contain an IEEE implementation.  It's just a Simple
Matter Of Programming.
From jimb@cygnus.com Wed Nov 10 12:35:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: MMX: Messy Multimedia eXtensions
Date: Wed, 10 Nov 1999 12:35:00 -0000
Message-id: <np66zaaxuq.fsf@zwingli.cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <5mso2eqi09.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00248.html
Content-length: 4686

> Jim> You can print MMX registers, too, but it's messier, since GDB doesn't
> Jim> know whether it's eight 8-bit values, four 16-bit values, et cetera:
> 
> Jim>     (gdb) p $mm2
> Jim>     $1 = {v8qi = {f = "\001\000\001\000\001\000\001"}, v4hi = {f = {1,
> Jim>       1, 1, 1}}, v2si = {f = {65537, 65537}}, uint64 = 281479271743489}
> 
> Jim> (Please ignore the fact that the eight 8-bit integers are printed as
> Jim> characters.  I'm going to fix that.)
> 
> It appears that the registers are represented by a union or struct.
> Can individual elements be used in GDB expressions?  If so, can you
> show how to represent the least significant byte in a mmx register?
> If not, I think this is a very serious deficiency.

Sure, it's a genuine union:

    (gdb) p $mm2
    $3 = {v8qi = {f = "\001\000\001\000\001\000\001"}, v4hi = {f = {1, 1, 1, 1}}, 
      v2si = {f = {65537, 65537}}, uint64 = 281479271743489}
    (gdb) p $mm2.v8qi
    $4 = {f = "\001\000\001\000\001\000\001"}
    (gdb) p $mm2.v8qi.f[0]
    $5 = 1 '\001'
    (gdb) set $mm2.v8qi.f[0] = 42
    (gdb) p $mm2
    $6 = {v8qi = {f = "*\000\001\000\001\000\001"}, v4hi = {f = {42, 1, 1, 1}}, 
      v2si = {f = {65578, 65537}}, uint64 = 281479271743530}
    (gdb) 

Is that what you wanted to do?

I agree that this is verbose, and I'm open to suggestions.  We could
define more register views whose names indicated what interpretation
you want to take.  But I'm not sure that $mm2v8qi is so much better
than $mm2.v8qi, and the latter has the advantage that it's guessable
given the results of `print $mm2'.  (Or at least, I thought it was.)

> There doesn't appear to be an entry in the MMX union for the single
> precision FP values in AMD's 3DNow extensions.  Wearing my GNU hat,
> (rather than my Cygnus-shareholder hat), I'd be very disapointed if
> this got integrated into GDB without AMD 3DNow support even if Intel
> funded Cygnus to do MMX work.

No conspiracy here.  It'd be an hour's work, if that, to add 3DNow
register views.  Here is all the architecture-specific code for the
MMX regs:

From config/i386/tm-i386.h:

/* GDB provides register views for the MMX registers.  */
#define IS_REGISTER_VIEW_NAME i386_is_register_view_name
#define REGISTER_VIEW_NAME(i) (i386_register_view_name[(i)])
#define REGISTER_VIEW_REGNO(i) (i386_register_view_regno[(i)])
#define REGISTER_VIEW_TYPE(i) (i386_register_view_type[(i)])

extern int i386_is_register_view_name (char *name, int len);
extern char *i386_register_view_name[];
extern int i386_register_view_regno[];
extern struct type *i386_register_view_type[];


And from i386-tdep.c:

/* Register views --- providing access to the MMX registers.  */

char *i386_register_view_name[] = { 
  /* The MMX registers.  */
  "mm0", "mm1", "mm2", "mm3", "mm4", "mm5", "mm6", "mm7"
};
#define NUM_REGISTER_VIEWS				\
  (sizeof (i386_register_view_name)		\
   / sizeof (i386_register_view_name[0]))

#define FIRST_MMX_VIEW 0
#define LAST_MMX_VIEW 7

int i386_register_view_regno[] = {
  FP0_REGNUM + 0, FP0_REGNUM + 1, FP0_REGNUM + 2, FP0_REGNUM + 3, 
  FP0_REGNUM + 4, FP0_REGNUM + 5, FP0_REGNUM + 6, FP0_REGNUM + 7
};

struct type *i386_register_view_type[NUM_REGISTER_VIEWS];

int
i386_is_register_view_name (char *name, int len)
{
  int i;

  for (i = 0; i < NUM_REGISTER_VIEWS; i++)
    {
      /* long variable names suck */
      char *view_name = i386_register_view_name[i];

      if (len == strlen (view_name)
	  && ! memcmp (name, view_name, len))
	return i;
    }

  return -1;
}

static void
init_register_view_types ()
{
  /* Construct a type for the MMX registers, and then plug it into the
     register view type array.  The type we're building is this:
     
     union __builtin_mmx {
       struct __builtin_v8qi v8qi;
       struct __builtin_v4hi v4hi;
       struct __builtin_v2si v2si;
       uint64_t uint64;
     };

     Now stick *that* in your pipeline and smoke it.  */

  struct type *t;
  struct field *f;
  int i;

  f = (struct field *) xmalloc (sizeof (*f) * 4);
  memset (f, 0, sizeof (*f) * 4);

  f[0].type = builtin_type_v8qi;
  f[0].name = "v8qi";

  f[1].type = builtin_type_v4hi;
  f[1].name = "v4hi";

  f[2].type = builtin_type_v2si;
  f[2].name = "v2si";

  f[3].type = builtin_type_int64;
  f[3].name = "uint64";

  /* Build a union type with those fields.  */
  t = init_type (TYPE_CODE_UNION, 8, 0, 0, 0);
  t->nfields = 4;
  t->fields = f;
  t->tag_name = "__builtin_mmx";

  /* Fill in the register view type table with it.  */
  for (i = FIRST_MMX_VIEW; i <= LAST_MMX_VIEW; i++)
    i386_register_view_type[i] = t;
}


To support 3DNow, either extend the __builtin_mmx union, or define a
new type and new view names.
From kettenis@wins.uva.nl Wed Nov 10 13:44:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 13:44:00 -0000
Message-id: <199911102143.WAA00385@delius.kettenis.local>
References: <199911090018.TAA12933@zwingli.cygnus.com> <199911100048.BAA00256@delius.kettenis.local> <npiu3ab4dl.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00249.html
Content-length: 801

   From: Jim Blandy <jimb@cygnus.com>
   Date: 10 Nov 1999 13:14:46 -0500

   > Maybe it would be a good idea to change the #defines of the register
   > numbers such that they match the names that GDB uses in its output,
   > i.e. FISEG_REGNUM instead of FCS_REGNUM, etc.

   Yeah, that was the original intent, but I forgot to change the CPP
   symbol names when I renamed the registers.  Rats; I wish I'd noticed
   this before Chris and Eli started adapting their tm-*.h files.  Let's
   wait on this until folks have submitted changes for their ports, and
   then I can make all the changes atomically with `M-x
   tags-query-replace'.

Personally I would prefer the change to happen ASAP.  I would be happy
to resubmit a patch if the change happened in the same interval as my
submission.

Mark
From eliz@gnu.org Wed Nov 10 14:31:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: kettenis@wins.uva.nl, cgf@cygnus.com, jtc@redbacknetworks.com, jkj@sco.com, hjl@valinux.com, gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 14:31:00 -0000
Message-id: <199911102231.RAA01251@mescaline.gnu.org>
References: <199911090018.TAA12933@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00250.html
Content-length: 1495

> - How should i386 targets handle the x86 FPU's 80-bit float type?  How
>   can we make sure that hosts capable of handling it properly don't
>   perform lossy conversions?

I think we need some HAVE_* style macro(s) for this.  Given that there
is some #define'd symbol that tells whether long double is supported,
the definition of REGISTER_CONVERT_TO_{RAW,VIRTUAL} should take into
account whether long doubles are supported or not, and DTRT.

I'm guessing that every x86 platform that supports 80-bit FP type
already has such macros (DJGPP defines LD_387 and uses
HAVE_LONG_DOUBLE).  What we need is to unify these into a single set
of x86-specific macros.

One problem that bothers me is that we must define the size of long
double to be 96 to have it supported.  This sounds like some hidden
dependency somewhere in GDB.  No platform should be forced to lie to
GDB about the actual size of its 80-bit float type to get this
support.  What would it take to solve this problem?

> Notably missing from this list are any other questions about tm-i386.h
> as it stands.  Am I correct in thinking that the other x86 port
> maintainers think it's basically sane?

I think it is sane and very useful.  Using it, tm-go32.h went from 211
lines to just 77!

> If so, I encourage folks to start deleting stuff from their more
> specialized tm-*.h files, and using the definitions in tm-i386.h.

Diffs sent to gdb-patches.  I took the opportunity to catch up with
other *-go32.h files in config/i386.
From cottons@concmp.com Wed Nov 10 15:46:00 1999
From: <cottons@concmp.com>
To: gdb@sourceware.cygnus.com
Subject: dwarf2 call frame information?
Date: Wed, 10 Nov 1999 15:46:00 -0000
Message-id: <19991110214314.20458.qmail@bagua.concmp.com>
X-SW-Source: 1999-q4/msg00251.html
Content-length: 83

Are there any plans to support dwarf2 call frame information in gdb?

    - Cotton
From eliz@gnu.org Wed Nov 10 21:54:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: MMX: Messy Multimedia eXtensions
Date: Wed, 10 Nov 1999 21:54:00 -0000
Message-id: <199911110554.AAA04263@mescaline.gnu.org>
References: <199911090706.CAA13120@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00252.html
Content-length: 1580

Here are my $0.02 on this:

> - Assign them register numbers separate from the FP stack registers'.
> - Assign them the same numbers as the FP stack registers, and treat them as
>   an alternative way of looking at the FP registers' mantissas.
> The first approach has some problems

Right.  If we do NOT treat the FP and MMX registers as the same
registers, we are in for a lot of trouble.  the only sane way is to
treat them as different views of the same register set.

> The problem is, we're using the same register number for %mm0 and
> %st(0), but %mm0 doesn't really correspond to %st(0).  It depends on
> the value of the FPU TOS register.

Yes, this is not right.  $mm0 should correspond to R0, not to $st0.
However, I don't think it is wise to rely on the program's code to
play by the rules (which effectively guarantee that $mm0 corresponds
to $st0).  Some clever programmer out there is bound to produce code
that uses FP instructions on data left from MMX instructions without
issuing EMMS in between.  GDB should not be confused by such code.

But why is this a problem?  Can't we make the correspondence be
dynamically computed at run time, using the current TOS?  If not, why
not?

One further thought about MMX-related issues:

 * I think we need a function to detect at run time whether MMX (and
   SSE, for that matter) are supported.  The fact that a given
   platform supports these extensions *in principle* does not mean
   that the particular target I'm debugging now does.  If MMX is not
   supported, GDB should not allow to look at the MMX registers.
From jtc@redback.com Fri Nov 12 11:11:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Fri, 12 Nov 1999 11:11:00 -0000
Message-id: <5md7tfttjv.fsf@jtc.redbacknetworks.com>
References: <199911090018.TAA12933@zwingli.cygnus.com> <5myac6qj3f.fsf@jtc.redbacknetworks.com> <np7ljqayuw.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00253.html
Content-length: 786

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
Jim> Great.  So, which tm-*.h file do you guys actually use?  Which
Jim> regset can we delete?  My guess would be tm-i386v.h.  A lot of
Jim> other tm.h files #include that, but all but tm-vxworks.h and
Jim> tm-i386sco5.h just override them.

I agree.  

Looking at what will be left of tm-i386v.h after the regset cruft is
removed, it may be more appropriate for tm-vxworks.h to inherit from
tm-i386.h directly instead of using tm-i386v.h.  But there's no need
to wait for that to procede.  Likewise, there should be a tm-embed.h
for raw embedded targets which inherits from either tm-i386.h or
tm-i386v.h, instead of using tm-i386v.h directly.  I'll submit such a
patch later today.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From obachman@mathematik.uni-kl.de Fri Nov 12 11:53:00 1999
From: Olaf Bachmann <obachman@mathematik.uni-kl.de>
To: gdb@sourceware.cygnus.com
Subject: [Q]: Obtaining Stack Trace
Date: Fri, 12 Nov 1999 11:53:00 -0000
Message-id: <m11mMkW-000F3HC@nepomuck.mathematik.uni-kl.de>
X-SW-Source: 1999-q4/msg00254.html
Content-length: 835

Hi,
I'm writing a new memory management system for our Computer Algebra
system Singular (written in C). For a special debug mode, I'd like to
associate (and store) with each allocated address enough (stack)
information, so that, on a later request, I basically get what the gdb
command 'backtrace' had printed at the time the allocation request was 
made. 

Could you please give me some hints on how I could reuse some of gdb's 
code and technologie so that I can accomplish this?

Thanks,
Olaf
____________________________________________________________________________
Olaf Bachmann              | Phone: + 49-631/205 2738 (work)
Centre for Computer Algebra|	    + 49-6306/7396    (home)
Fachbereich Mathematik     | Email: obachman@mathematik.uni-kl.de
Universitaet Kaiserslautern| URL: http://www.mathematik.uni-kl.de/~obachman