Re: annotate.texi

[Eli Zaretskii <eliz@delorie.com>]

> > 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 <eliz@delorie.com>
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 <eliz@delorie.com>
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 <eliz@delorie.com>
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" <sharathibm@theglobe.com>
To: gdb@sourceware.cygnus.com
Subject: target_read_memory for breakpoints
Date: Wed, 08 Mar 2000 05:38:00 -0000
Message-id: <GAMLDEKNADAJKAAA@theglobe.com>
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 <johan.rydberg@netinsight.se>
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 <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Wed, 08 Mar 2000 06:04:00 -0000
Message-id: <bsny1fths.fsf@rtl.cygnus.com>
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 <kingdon@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: annotate.texi
Date: Wed, 08 Mar 2000 06:12:00 -0000
Message-id: <br9dlft4v.fsf@rtl.cygnus.com>
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 <eliz@delorie.com>
To: Jim Kingdon <kingdon@redhat.com>
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: <br9dlft4v.fsf@rtl.cygnus.com> <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.