From: Eli Zaretskii <eliz@delorie.com>
To: jtc@redback.com
Cc: msalter@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: Remote watchpoint support.
Date: Tue, 31 Oct 2000 01:07:00 -0000 [thread overview]
Message-ID: <200010310906.EAA21820@indy.delorie.com> (raw)
In-Reply-To: <5mg0leoyg6.fsf@jtc.redback.com>
> From: jtc@redback.com (J.T. Conklin)
> Date: 30 Oct 2000 12:39:53 -0800
>
> One thing I dislike about it is that the debug agent never explicitly
> tells GDB that a watchpoint has been hit, but rather it is implicitly
> coded in the return value of the query.
I agree that this is not a good design.
> The second is the return value of 0 if the target stopped for another
> reason. I (now) know that this is the current behavior of the target_
> stopped_data_address() macro, but it use the one address that I think
> might be very important to watch on targets where the zero page isn't
> unmapped (in which case a reference would cause a exception/trap).
I would actually be very happy if we could change the interface of
target_stopped_data_address so that zero would not be treated
specially. One problem with the current design is that I cannot catch
NULL pointer dereferences on Windows, where the null page cannot be
unmapped from the address space of DJGPP programs. This prevents me
from finding such bugs by setting a watchpoint at address 0.
> While it might not be possible to fix in GDB's internals for some
> time
What would it take to change that? Perhaps it would be a good idea to
have the list of the obstacles, in case someone might try to negotiate
them one by one.
From eliz@delorie.com Tue Oct 31 01:09:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: john@Calva.COM
Cc: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, gdb-patches@sources.redhat.com
Subject: Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare
Date: Tue, 31 Oct 2000 01:09:00 -0000
Message-id: <200010310906.EAA21817@indy.delorie.com>
References: <NCBBLMGKIKDGJMEOMNMEEEDMHEAA.john@Calva.COM>
X-SW-Source: 2000-10/msg00294.html
Content-length: 1008
> From: "John Hughes" <john@Calva.COM>
> Date: Mon, 30 Oct 2000 17:11:58 +0100
>
> > But all the i386v4-nat.c code has to be conditionalized on
> > UNIXWARE (or better yet, moved to a new i386sco-nat.c file), as
> > i386v4-nat.c is used by x86 Solaris as well, and Solaris uses page
> > faulting instead of debug registers for watchpoints, and would not
> > compile with your patches installed.
>
> Aha. Here's a fixed version of the patch; the i386v4-nat.c changes
> are conditional on UNIXWARE.
Note that I'm working on a unified watchpoint implementation for all
ia32 targets, based on the code written for the DJGPP port (see
go32-nat.c). This implementation will allow to watch large areas (up
to 16 bytes) and debug register sharing via reference counts (required
for watching overlapping areas) on all ia32 platforms.
I am trying to make this happen for v5.1, so perhaps changes like this
one should be witheld and not committed, at least until we decide that
I'm not living up to my promises.
From kettenis@wins.uva.nl Tue Oct 31 01:37:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: msnyder@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com, kevinb@cygnus.com
Subject: Re: [PATCH]: Extend SVR4 shlib debug changes to SH3 and other targets
Date: Tue, 31 Oct 2000 01:37:00 -0000
Message-id: <200010310937.e9V9b4604953@debye.wins.uva.nl>
References: <200010310102.RAA24876@cleaver.cygnus.com>
X-SW-Source: 2000-10/msg00295.html
Content-length: 2239
From: Michael Snyder <msnyder@cygnus.com>
Date: Mon, 30 Oct 2000 17:02:01 -0800 (PST)
This change moves the definition of SVR4_SHARED_LIBS into
config/tm-linux.h, so that it will affect all linuxen.
I then add a new file config/sh/tm-linux.h which includes
config/tm-linux.h (as well as sh/tm-sh.h). Finally I add
target-specific definitions of fetch_link_map_offsets, so
that shared libraries can be cross-debugged.
2000-10-30 Michael Snyder <msnyder@cleaver.cygnus.com>
* config/sh/tm-linux.h: New file. Include generic tm-linux.h,
plus tm-sh.h, then define SVR4_FETCH_LINK_MAP_OFFSETS to use
the sh target function instead of the default link map offsets.
* config/sh/sh.mt: Add solib.o and solib-svr4.o to TDEPFILES.
Use sh/tm-linux.h instead of sh/tm-sh.h.
* sh-tdep.c (sh_linux_svr4_fetch_link_map_offsets):
New function. Construct target-specific link map offsets.
* i386-linux-tdep.c (i386_linux_svr4_fetch_link_map_offsets:
New function. Construct target-specific link map offsets.
* config/i386/tm-linux.h: Use above function instead of default.
2000-10-30 Michael Snyder <msnyder@cleaver.cygnus.com>
* config/i386/tm-linux.h: Remove definition of SVR4_SHARED_LIBS,
and inclusion of solib.h. Move up into ../tm-linux.h.
config/tm-linux.h: Define SVR4_SHARED_LIBS, include solib.h.
Looks good to me. One minor nit though:
Index: config/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/tm-linux.h,v
retrieving revision 1.1.1.1
diff -c -3 -p -r1.1.1.1 tm-linux.h
*** tm-linux.h 1999/12/07 03:56:08 1.1.1.1
--- tm-linux.h 2000/10/31 00:57:12
***************
*** 34,36 ****
--- 34,42 ----
/* We need this file for the SOLIB_TRAMPOLINE stuff. */
#include "tm-sysv4.h"
+
+ /* We define this if link.h is available, because with ELF we use SVR4 style
+ shared libraries. FIXME: move up into config/tm-linux.h? */
+
+ #define SVR4_SHARED_LIBS
+ #include "solib.h" /* Support for shared libraries. */
Please update the comment. The FIXME can go now, and the blurb about
link.h isn't true anymore isn't it?
From john@Calva.COM Tue Oct 31 03:20:00 2000
From: "John Hughes" <john@Calva.COM>
To: "Eli Zaretskii" <eliz@is.elta.co.il>
Cc: <gdb-patches@sources.redhat.com>
Subject: RE: Patch for gdb5.0; enable hardware watchpoints on UnixWare
Date: Tue, 31 Oct 2000 03:20:00 -0000
Message-id: <NCBBLMGKIKDGJMEOMNMEMEELHEAA.john@Calva.COM>
References: <200010310906.EAA21817@indy.delorie.com>
X-SW-Source: 2000-10/msg00296.html
Content-length: 2169
Eli Zaretskii writes:
> Note that I'm working on a unified watchpoint implementation for all
> ia32 targets, based on the code written for the DJGPP port (see
> go32-nat.c).
Ah good. I saw the stuff in TODO yesterday and was trying to work up
the courage to propose doing this myself.
> I am trying to make this happen for v5.1, so perhaps changes like this
> one should be witheld and not committed, at least until we decide that
> I'm not living up to my promises.
Oh, please ignore my patch then, could you steal the svr42mp specific
bits of it for 5.1? (debug registers held in pr_family element of
proc status, PCSDEBUG operation to write debug registers).
Looking at version 1.6 of go32-nat.c I've got a couple of comments:
1. Why not zap the waddr arg to go32_..._watchpoint? It's not used.
2. In go32_insert_aligned_watchpoint (and ...remove_aligned...) you
have a "switch" to work out the len_bits for the watchpoint, then a
loop to find an existing watchpoint that might match, then an
"if" to check for non-aligned watchpoints. (Which could not have
matched in the loop).
It seems to me this could be simplified to:
...
if (addr % len)
return go32_handle_nonaligned_watchpoint (wp_insert, addr, len, rw);
switch (len)
{
case 4:
len_bits = DR_LEN_4;
break;
case 2:
len_bits = DR_LEN_2;
break;
case 1:
len_bits = DR_LEN_1;
break;
default:
return go32_handle_nonaligned_watchpoint (wp_insert, addr, len, rw);
}
/* Look for an occupied debug register with the same address and the
same RW and LEN definitions. If we find one, we can use it for
this watchpoint as well (and save a register). */
...
3. You're not using the DR_FIRSADDR/DR_LASTADDR defines.
4. You have a define DR_RW_READWRITE, other people (SVR3/SVR4/SVR5) seem
to have DR_RW_READ with the same value (0x3).
5. Not everybody has DR_CONTROL_MASK.
#define DR_CONTROL_MASK ((1<<DR_CONTROL_SIZE) - 1)
--
John Hughes <john@Calva.COM>,
CalvaEDI SA. Tel: +33-1-4313-3131
66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139
75013 PARIS.
next prev parent reply other threads:[~2000-10-31 1:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200010301416.e9UEG6m18981@deneb.localdomain>
[not found] ` <39FDCF55.46BD@redhat.com>
[not found] ` <200010302018.e9UKIr300876@deneb.localdomain>
2000-10-30 12:21 ` Michael Snyder
[not found] ` <5mg0leoyg6.fsf@jtc.redback.com>
2000-10-31 1:07 ` Eli Zaretskii [this message]
[not found] <200011012131.eA1LVa514840@deneb.localdomain>
2000-11-06 4:08 ` remote " Andrew Cagney
2000-11-06 5:51 ` Mark Salter
2001-06-28 15:09 ` Andrew Cagney
2001-06-28 16:17 ` Mark Salter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200010310906.EAA21820@indy.delorie.com \
--to=eliz@delorie.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jtc@redback.com \
--cc=msalter@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox