> > Is there any reason why annotate.texi shouldn't be @include'd by > > gdb.texinfo and be part of the manual? Right now, "set annotate" is > > not documented at all, and annotate.texi seems to be just what the > > doctor ordered... > > This is on my long-term wish list for the manual, along with agentexpr > info. So, will it be okay to submit a change to gdb.texinfo to include annotate.texi (and add the appropriate menu items to gdb.texinfo)? IMHO, no matter how incomplete annotate.texi might be, it is still MUCH better than not telling anything about this feature. > > And while at that, NEWS seems to be in the need of some work, it > > doesn't mention many of the new features that already are in the CVS > > tree. I would like at least to mention the improvements in the DJGPP > > version. > > Yes please. Will do. > But seriously, everybody doing a checkin should ask themselves: will > users want to know about this change? Usually the answer will be > yes; users complain about lack of information far more often than > about overloaded... The manual is also in dire need of more indexing. I find myself using (the inefficient) search command too much, instead of (the superb) index-search. Simple search is painful in a large manual. I'm trying to add some indexing whenever I can. But I suggest that every manual patch be scrutinized for appropriate index entries, and that this policy be published in the guidelines. From eliz@delorie.com Wed Mar 08 02:09:00 2000 From: Eli Zaretskii To: hjl@valinux.com Cc: gdb@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Wed, 08 Mar 2000 02:09:00 -0000 Message-id: <200003081008.FAA16481@indy.delorie.com> References: <20000307132401.A20282@valinux.com> X-SW-Source: 2000-03/msg00130.html Content-length: 1624 > Starting program: /home/hjl/bugs/gdb/hw/y > warning: Could not insert hardware watchpoint 1. > warning: Could not insert hardware watchpoint 3. > ptrace: Unknown error 4294967295. > Cannot insert breakpoints. > The same program may be running in another process. > (gdb) > > ia32 only has 4 hardware debug registers. But gdb shouldn't crash. I don't see any crashes in the above script. GDB simply didn't start the process. It is arguable whether it should instead proceed after inserting only those watchpoints it can, but I agree that it should at least be a user option. > Even worse, after deleted one hardware watchpoint, gdb still refused > to work. It works for me, but I have patches to do that, which I'm trying for 6 months to get accepted :-(. Those patches also correct numerous other problems with watchpoints on x86, which you didn't mention. For example, try setting several watchpoints (of different types) on the same variable, and see the mess. Another problem which I corrected is that you cannot watch struct members, array elements, and bit fields with hardware-assisted watchpoints. > (gdb) watch a1 > Watchpoint 1: a1 > (gdb) watch a2 > Watchpoint 2: a2 > (gdb) > > gdb won't set hardware watchpoints on long long nor double. You could look at go32-nat.c, it supports watching any region up to 16 bytes large. (I'm at a loss how come DJGPP needed to invent this: I'd expect any x86 platform to have this already, since watchpoints are such an indispensable tool in some circumstances.) > I will send in a patch in another email. Please see my response with objections to your patch. From eliz@delorie.com Wed Mar 08 02:14:00 2000 From: Eli Zaretskii To: hjl@valinux.com Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A patch for ia32 hardware watchpoint. Date: Wed, 08 Mar 2000 02:14:00 -0000 Message-id: <200003081012.FAA16486@indy.delorie.com> References: <20000307132613.B20282@valinux.com> X-SW-Source: 2000-03/msg00131.html Content-length: 3231 > This is a patch for > > http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00564.html I have problems with this patch. See below. > I only did it for Linux since it is not a perfect solution. No, you also changed nm-go32.h, which is not related to Linux (AFAIK), and changed the global definition of two macros on breakpoint.c. > +#ifdef NEED_WATCHPOINT_NUMBER > + val = target_insert_watchpoint (b->number, addr, > + len, type); > +#else Please explain why is this needed. The DJGPP version works well without knowing the breakpoint number, but if there's a good reason for passing b->number, it should be done on all x86 platforms. So let's discuss this. > + /* Don't return an error if we fail to insert > + a hardware watchpoint due to the limited number > + of hardware watchpoints availabel. */ > + val = (errno == EBUSY) ? 0 : -1; > + } Why is this a good idea? The result of this is that GDB will not know that it cannot insert a watchpoint until it actually resumes the debuggee, which is too late in many cases; and the user gets confusing error messages. x86 doesn't have a good way of checking whether the debug registers are enough to cover the requests, but whenever it does, why not use it? > @@ -5500,13 +5513,13 @@ watch_command_1 (arg, accessflag, from_t > in hardware return zero. */ > > #if !defined(TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT) > -#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(BYTE_SIZE) \ > - ((BYTE_SIZE) <= (REGISTER_SIZE)) > +#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) \ > + (TYPE_LENGTH (VALUE_TYPE (VAL)) <= (REGISTER_SIZE)) > #endif > > #if !defined(TARGET_REGION_OK_FOR_HW_WATCHPOINT) > -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(ADDR,LEN) \ > - TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(LEN) > +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(VAL) \ > + TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) > #endif These are IMHO wrong: the number of debug registers required for a particular region is a function of the address, not only size (e.g., a single x86 debug register cannot watch a 32-bit region that isn't aligned on 4-byte boundary). If Linux, for some reason, doesn't need the address (although I cannot see how could this be right, at least for native debugging), please define a platform-specific macro instead of overwriting system-wide defaults. The DJGPP version actually *uses* the ADDR part of the above definition, since it knows how to cover a region with several watchpoints. > --- config/i386/nm-go32.h 2000/03/07 18:42:21 1.1.1.2 > +++ config/i386/nm-go32.h 2000/03/07 18:53:48 > @@ -44,10 +44,10 @@ > #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1 > > /* Returns non-zero if we can use hardware watchpoints to watch a region > - whose address is ADDR and whose length is LEN. */ > + which represents VAL. */ > > -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(addr,len) \ > - go32_region_ok_for_watchpoint(addr,len) > +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(val) \ > + go32_region_ok_for_watchpoint((VALUE_ADDRESS (val) + VALUE_OFFSET (val)),TYPE_LENGTH (VALUE_TYPE (val))) Please do not commit this one, it disables a valuable feature in the DJGPP version. From eliz@delorie.com Wed Mar 08 03:32:00 2000 From: Eli Zaretskii To: hjl@valinux.com Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A patch for ia32 hardware watchpoint. Date: Wed, 08 Mar 2000 03:32:00 -0000 Message-id: <200003081132.GAA16847@indy.delorie.com> References: <20000307132613.B20282@valinux.com> X-SW-Source: 2000-03/msg00132.html Content-length: 1455 > > @@ -5500,13 +5513,13 @@ watch_command_1 (arg, accessflag, from_t > > in hardware return zero. */ > > > > #if !defined(TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT) > > -#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(BYTE_SIZE) \ > > - ((BYTE_SIZE) <= (REGISTER_SIZE)) > > +#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) \ > > + (TYPE_LENGTH (VALUE_TYPE (VAL)) <= (REGISTER_SIZE)) > > #endif > > > > #if !defined(TARGET_REGION_OK_FOR_HW_WATCHPOINT) > > -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(ADDR,LEN) \ > > - TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(LEN) > > +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(VAL) \ > > + TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) > > #endif > > These are IMHO wrong: the number of debug registers required for a > particular region is a function of the address, not only size (e.g., a > single x86 debug register cannot watch a 32-bit region that isn't > aligned on 4-byte boundary). If Linux, for some reason, doesn't need > the address (although I cannot see how could this be right, at least > for native debugging), please define a platform-specific macro instead > of overwriting system-wide defaults. Sorry, I talked too soon. These changes supply all the required info, since they pass the entire struct value to the macro. So they are okay with me. I'm terribly sorry for jumping the gun for no reason. The rest of my comments about these patches are still valid, though. From sharathibm@theglobe.com Wed Mar 08 05:38:00 2000 From: "Sharath Kumar" To: gdb@sourceware.cygnus.com Subject: target_read_memory for breakpoints Date: Wed, 08 Mar 2000 05:38:00 -0000 Message-id: X-SW-Source: 2000-03/msg00133.html Content-length: 552 Hi I was just trying to find how breakpoints are set/hit..and i came across this function - 'target_read_memory' which calls 'target_xfer_memory' which inturn calls - "current_target.to_xfer_memory". I am not able to proceed after this.. I actually want to know the implementation of "hitting of the breakpoint" and then "continuing after the breakpoint". (for intel pentium arch.) Do you have any suggesstions? regards, Sharath. theglobe.com Your friendly full-service integrated online community. http://www.theglobe.com From johan.rydberg@netinsight.se Wed Mar 08 05:59:00 2000 From: Johan Rydberg To: gdb@sourceware.cygnus.com Subject: problem with register display Date: Wed, 08 Mar 2000 05:59:00 -0000 Message-id: <38C6691D.C3F05223@netinsight.se> X-SW-Source: 2000-03/msg00134.html Content-length: 665 Hi! I'm developing a "gdb-simulator" for a CPU, and it seems to work pretty good. But I have some questions. When I try to display the registers it says everyone except the link register is unavailable. Why this? It also fetches the PC register, but it also says it's unavailable. And, how do I from gdb call the `sim_info´ function? Right now I have implemented a "sim info" command, but since it's defined in the simulator interface I guess that there's a better way to do this. -- Johan Rydberg johan.rydberg@netinsight.net Net Insight AB, Sweden direct: +46-8-685 04 17 http://www.netinsight.net phone: +46-8-685 04 00 fax: +46-8-685 04 20 From kingdon@redhat.com Wed Mar 08 06:04:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: A patch for ia32 hardware watchpoint. Date: Wed, 08 Mar 2000 06:04:00 -0000 Message-id: References: <200003080845.AAA18410@alabama.wrs.com> X-SW-Source: 2000-03/msg00135.html Content-length: 1547 > Yeah. This is about as bad as crunching target events through unix > signals, something that only ever made sense on ptrace() targets > which couldn't do any better. "But the code lives on" Always amusing to hear people talking about my designs :-) (also see comment in target.h at enum target_signal). The deep question is whether you want GDB to canonicalize things. I do see some value in getting (for example) a SEGV when you access memory which is not mapped by the MMU (if you have one) across all targets. Both for users and for scripts. If you answer pro-canonical, then the right solution is to add additional fields (most native platforms have arch-dependent signal codes, for example, and GDB could be taught to pass them along or generate them for stubs and such). I think that ptrace() targets could get at the signal codes but not necessarily in a clean way (wait4 and friends don't seem to return them). If you answer anti-canonical, then you want functions in the target vector to do things like report stop status to the user. The two approaches aren't mutually exclusive, actually, we probably want both a canonicalized status and a way to get more specific information in a free-form way. The situation might be analogous for errno, although errno is such a poor fit for things which happen to targets (e.g. "address out of range" maps to EIO. Bletch), that I kind of doubt it is worth the bother to do the canonicalization thing. Unless perhaps if we wanted to come up with a GDB-specific canonical set of errors. From kingdon@redhat.com Wed Mar 08 06:12:00 2000 From: Jim Kingdon To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: annotate.texi Date: Wed, 08 Mar 2000 06:12:00 -0000 Message-id: References: <200003070832.DAA14451@indy.delorie.com> <38C55BEE.D8E6F7BE@apple.com> <200003081003.FAA16478@indy.delorie.com> X-SW-Source: 2000-03/msg00136.html Content-length: 488 > I'm trying to add some indexing whenever I can. But I suggest that > every manual patch be scrutinized for appropriate index entries Sounds like the voice of someone volunteering to do some scrutinization ;-). Believe me, "people sending in lots of manual patches which never get merged" just hasn't been a problem on any free software project I've worked on. Having Stan as the documentation maintainer is a good thing too, because we are willing to hurt him if he slacks off :-). From eliz@delorie.com Wed Mar 08 06:23:00 2000 From: Eli Zaretskii To: Jim Kingdon Cc: gdb@sourceware.cygnus.com, shebs@apple.com Subject: Re: annotate.texi Date: Wed, 08 Mar 2000 06:23:00 -0000 Message-id: <200003081422.JAA17698@indy.delorie.com> References: <200003070832.DAA14451@indy.delorie.com> <38C55BEE.D8E6F7BE@apple.com> <200003081003.FAA16478@indy.delorie.com> X-SW-Source: 2000-03/msg00137.html Content-length: 677 Jim Kingdon writes: > > I'm trying to add some indexing whenever I can. But I suggest that > > every manual patch be scrutinized for appropriate index entries > > Sounds like the voice of someone volunteering to do some scrutinization ;-). If that's what it takes to make this happen, then yes, I do volunteer. But I do request that this be declared as an official policy, so that individual contributors could be requested to add the index entries, if the manual changes are large. Adding an index entry to a typical manual patch is really a small nuisance. It's only when you need to add them all at once to a large manual, only then the job becomes too large to bear.