From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Duffek To: dberlin@redhat.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] C++ method calls Date: Sat, 08 Jul 2000 22:18:00 -0000 Message-id: <200007090523.e695Nns01046@rtl.cygnus.com> References: <863dlkatux.fsf@dan2.cygnus.com> X-SW-Source: 2000-07/msg00090.html On 8-Jul-2000, Daniel Berlin+list . gdb-patches wrote: >I probably missed this one because in DWARF2, which is what i'm almost >always using, unless we hit hash table collisions, which we almost never >do (you'd need a *lot* of type names), == should be sufficient to compare >type names when dealing with C++. The case I noticed was when both names were NULL, as happens when checking TYPE_CODE_PTR args. >You do realize, of course, that the fact that it isn't means you are >duplicating info when reading in STABS/DBX/whatever debug format you are >using, that you shouldn't be. In the absence of a comment that type names are guaranteed to be ==, I figured it'd be safest to do a strcmp() rather than just a NULL check. >Feel free to apply them. Done, Nick >From nsd@redhat.com Sat Jul 08 22:21:00 2000 From: Nick Duffek To: dberlin@redhat.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] Fix C++ enum tests Date: Sat, 08 Jul 2000 22:21:00 -0000 Message-id: <200007090526.e695Qbg01049@rtl.cygnus.com> References: <867lawausv.fsf@dan2.cygnus.com> X-SW-Source: 2000-07/msg00091.html Content-length: 444 On 8-Jul-2000, Daniel Berlin+list . gdb-patches wrote: >Fine by me, dunno if it falls under my maintainership though, or Stans. Since you answered first, I'll assume you. :-) >Have you tested them with different debug info types? Not the enum test change, because it's so obviously broken (the misc.cc line number is just wrong). I did ad-hoc testing of my "C++ method calls" patch with DWARF-2, though. I've committed this change. Nick >From eliz@delorie.com Sat Jul 08 22:47:00 2000 From: Eli Zaretskii To: cgf@cygnus.com Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] doc/Makefile.in patch stolen from Makefile.am Date: Sat, 08 Jul 2000 22:47:00 -0000 Message-id: <200007090547.BAA25681@indy.delorie.com> References: <20000708013554.A13848@cygnus.com> X-SW-Source: 2000-07/msg00092.html Content-length: 373 > Date: Sat, 8 Jul 2000 01:35:54 -0400 > From: Chris Faylor > > >Could I suggest stealing the install-info-am: target from > >src/bfd/doc/Makefile.in? (calling it install-info: of course :-). > > Here it is. It was a lot easier than I thought it would be. > I should have just done this to begin with. I've just commited this (to the trunk). Thanks! >From fnasser@cygnus.com Sun Jul 09 09:58:00 2000 From: Fernando Nasser To: "Daniel Berlin+list.gdb-patches" Cc: Nick Duffek , gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] Fix C++ enum tests Date: Sun, 09 Jul 2000 09:58:00 -0000 Message-id: <3968AF20.7D05BF68@cygnus.com> References: <200007090121.e691LLV00837@rtl.cygnus.com> <867lawausv.fsf@dan2.cygnus.com> X-SW-Source: 2000-07/msg00093.html Content-length: 398 "Daniel Berlin+list.gdb-patches" wrote: > > Fine by me, dunno if it falls under my maintainership though, or Stans. It would be Stan and I. But the patch is obviously necessary. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From ezannoni@cygnus.com Sun Jul 09 12:12:00 2000 From: Elena Zannoni To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: readilne 4.1. is in Date: Sun, 09 Jul 2000 12:12:00 -0000 Message-id: <14696.52863.864411.260537@kwikemart.cygnus.com> X-SW-Source: 2000-07/msg00094.html Content-length: 742 Let me know if there are any problems building gdb. I took the item out of the TODO file as well. Elena Index: TODO =================================================================== RCS file: /cvs/src/src/gdb/TODO,v retrieving revision 1.37 diff -c -u -p -r1.37 TODO cvs server: conflicting specifications of output style --- TODO 2000/06/23 08:12:27 1.37 +++ TODO 2000/07/09 17:22:32 @@ -239,14 +239,6 @@ suffer bit rot. -- -Updated readline - -Readline 4.? is out. A merge wouldn't hurt. Patches are in: - - http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00436.html - --- - Deprecate "fg". Apparently ``fg'' is actually continue. http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00417.html >From ac131313@cygnus.com Sun Jul 09 19:59:00 2000 From: Andrew Cagney To: msnyder@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFC]: Pseudo-registers for GDB Date: Sun, 09 Jul 2000 19:59:00 -0000 Message-id: <39693C0D.223C4C8A@cygnus.com> References: <396632CB.55A1@cygnus.com> X-SW-Source: 2000-07/msg00095.html Content-length: 3527 [I suspect that I hit the wrong button half way though composing this] Michael Snyder wrote: > As a first step, I propose to move the register cache from > its present ill-concieved location in findvar.c into its own > module (tentatively named regcache.c), and to make it a true > data object (with access functions to replace the direct > access that some modules now make). After that, changes to > the data structure should have minimal impact on the rest of > GDB. > > Comments? Yes please! Well the first step has to be a good thing (tm). Right now we've no idea how various targets are using (and abusing) register_bytes[] so placing it under some sort of control means, as you point out, it can be re-implemented cleanly. Interestingly, this is the same first step that would need to be taken if there is to be a per-thread register cache. So definitly a good move! > 1) real vs. virtual frame pointer. > Many architectures have a dedicated frame pointer register, > but in some circumstances (eg. "frameless" leaf functions) > there is a virtual frame pointer that is not kept in a > register at all. In that case the value of the "frame location" > is different from the value of the '$fp' register. > > At present, GDB will report one value if you say > "info register $fp", and a different value if you say > "print $fp". > > With pseudo-registers, we could define a virtual FP register > in addition to the hardware FP register. The virtual one > would be computed rather than fetched from the target machine. > The confusion between the FP register and the virtual frame > pointer would be eliminated. In the case of the virtual-fp, since it really has nothing to do with the target, would it be better to keep it separate from *-tdep.c and hence regcache.[ch]? I suspect, looking at this pragmatically, that it is far more important to get the regcache.[hc] up and running than trying to also resolve this. > 2) register pairs. > Sometimes registers can be addressed either separately or > joined / concatenated together. For instance, MIPS has some > number of single-precision floating point registers, which can > be paired into half that number of double precision regs. > > We could treat the single-precision regs as real hardware > regs, and fetch them from the target as usual. The > combined (double precision) regs would be pseudo-regs; > addressable by name, but not needing to be fetched once > the single-precision ones are fetched or stored. They > would share the same storage in the register cache, even > as they share the same storage on the target machine. > > 3) vector registers. > Another example of shared storage. Some architectures can > have vector co-processors, where a largeish number of > register 'elements' are joined into one array of registers. > We could store the elements in the cache as discretely > addressable registers, and also define a single vector > register to address them all at once. With such large > registers, the disadvantage of fetching the values twice > are easy to see. A slightly more technical question. When GDB displays register information for the non-inner most frame, it uses a union of information obtained from both a ``struct frame'' and the register buffer. I guess the strategy here is to first get regcache.[ch] working and supporting virtual registers and then, later update the frame code so that it can handle things the same way. Assuming that is the stragegy then it is definitly a good move. Andrew >From ac131313@cygnus.com Sun Jul 09 20:27:00 2000 From: Andrew Cagney To: GDB Patches Subject: find_saved_register(frame) -> next/prev frame? Date: Sun, 09 Jul 2000 20:27:00 -0000 Message-id: <39694282.8066451A@cygnus.com> X-SW-Source: 2000-07/msg00096.html Content-length: 1595 Hello, The function find_saved_register() uses: /* Note that this next routine assumes that registers used in frame x will be saved only in the frame that x calls and frames interior to it. This is not true on the sparc, but the above macro takes care of it, so we should be all right. */ while (1) { QUIT; frame1 = get_prev_frame (frame1); if (frame1 == 0 || frame1 == frame) break; FRAME_INIT_SAVED_REGS (frame1); if (frame1->saved_regs[regnum]) addr = frame1->saved_regs[regnum]; } find the frame that contains a registers value. I'm right now very confused as I think it is looking in the wrong direction. Consider the stack: main() -> outer () saves r1, r2 -> middle () saves r2, r3 -> inner() saves r1, r3 lets assume that we've just selected the frame for middle(). I think we should find register values at: r1: in inner()' stack frame r2: in the register cache r3: in inner()'s stack frame Looking at the above implementation. My understanding of ``get_prev_frame()'' is that it goes to the next _outer_ frame. It should be calling get_next_frame() going to the next inner frame. It also appears to contract the comment attatched to the code. Can I rename get_next_frame() to get_inner_frame() and get_prev_frame() to get_outer_frame() :-) Andrew PS: I should note that this code has remained largely unchanged since '91 (which is as far back as CVS history goes!) so either something really wierd is going on or I'm missing something obvious - I guess we suspect the latter. >From thomasb@novagate.net Sun Jul 09 20:28:00 2000 From: Tom To: gdb-patches@sourceware.cygnus.com Subject: Ad: Are You Financially Healthy? Date: Sun, 09 Jul 2000 20:28:00 -0000 Message-id: <200007100328.XAA15753@mailgate.novagate.net> X-SW-Source: 2000-07/msg00097.html Content-length: 771 Thanks for posting to my FFA links page hosted by FFA-USA.net *************************************** Unleash the power of your computer and learn who to use it to become Financially FREE in 60 Minutes a Day! Sincerely: Tom Bell Holland, MI LFI: 20262162 http://hotyellow98.com/force2000/ ************************************************************************** Here's another program that has worked very well for me! It won't cost you a thing to take the tour. But it could cost you an early retirerment or a new car or any number of the things you have wanted but could'nt afford. If you don't at least check it out you will never know. http://hotyellow98.com/force2000/ **************************************************************************