From mboxrd@z Thu Jan 1 00:00:00 1970 From: cgf@cygnus.com (Chris Faylor) To: gdb@sourceware.cygnus.com Subject: Re: Debugging Windows Namespace extension dll Date: Tue, 09 Nov 1999 06:00:00 -0000 Message-id: <8099d4$kph$1@cronkite.cygnus.com> References: X-SW-Source: 1999-q4/msg00233.html In article < l03130305b44c7ccd1ad2@[138.251.135.28] >, Mark Hindley 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 >> 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 To: "H.J. Lu" Cc: GDB 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 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 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 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 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 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 To: Todd Whitesel Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: MMX: Messy Multimedia eXtensions Date: Wed, 10 Nov 1999 10:06:00 -0000 Message-id: 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 To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: i386: Are we settled? Date: Wed, 10 Nov 1999 10:08:00 -0000 Message-id: 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 To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: i386: Are we settled? Date: Wed, 10 Nov 1999 10:14:00 -0000 Message-id: 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 Cc: Mark Kettenis , Eli Zaretskii , Chris Faylor , "J. Kean Johnston" , "H. J. Lu" , 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 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 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 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 To: gdb@sourceware.cygnus.com Subject: env variables in command files Date: Wed, 10 Nov 1999 11:18:00 -0000 Message-id: 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 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: 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 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: 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 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> X-SW-Source: 1999-q4/msg00249.html Content-length: 801 From: Jim Blandy 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 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: 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 To: Jim Blandy 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 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> X-SW-Source: 1999-q4/msg00253.html Content-length: 786 >>>>> "Jim" == Jim Blandy 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 To: gdb@sourceware.cygnus.com Subject: [Q]: Obtaining Stack Trace Date: Fri, 12 Nov 1999 11:53:00 -0000 Message-id: 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