Shouldn't this patch be investigated/integrated into the beta
sources of gdb at sourceware.cygnus.com?
Marty Leisner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Shouldn't this patch be investigated/integrated into the beta
sources of gdb at sourceware.cygnus.com?
Marty Leisner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> From: Thomas David Rivers
>
> I just wondered if this should be integrated into ptrace(), so
> the various debuggers wouldn't have to know about it.
>
> It seems that would be the proper abstraction - hardware that supports
> it would "have it" - and the programs that "used it" wouldn't have
> From: Thomas David Rivers <[EMAIL PROTECTED]>
>
> I just wondered if this should be integrated into ptrace(), so
> the various debuggers wouldn't have to know about it.
>
> It seems that would be the proper abstraction - hardware that supports
> it would "have it" - and the programs that "us
I just wondered if this should be integrated into ptrace(), so
the various debuggers wouldn't have to know about it.
It seems that would be the proper abstraction - hardware that supports
it would "have it" - and the programs that "used it" wouldn't have to
know anything special.
I only have a
I just wondered if this should be integrated into ptrace(), so
the various debuggers wouldn't have to know about it.
It seems that would be the proper abstraction - hardware that supports
it would "have it" - and the programs that "used it" wouldn't have to
know anything special.
I only have
Hi,
(I've CC'd -current because of the implications there ...)
Here are my patches for hardware debug register support for the i386
port. I think this is ready to be reviewed and hopefully committed.
It consists of modifications to 13 files and the addition of 1 new
file. The new file is listed
Hi,
(I've CC'd -current because of the implications there ...)
Here are my patches for hardware debug register support for the i386
port. I think this is ready to be reviewed and hopefully committed.
It consists of modifications to 13 files and the addition of 1 new
file. The new file is liste
On Jul 07, 1999 at 10:25:12PM -0400, Brian Dean wrote:
> OK, I did that. What is the convention for naming the flags? The
> only one in use for that set of flags is FP_SOFTFP. I'm currently
> using PCB_DBREGS, but I but I easily change the name to whatever
> convention dictates - please advise.
On Jul 07, 1999 at 10:25:12PM -0400, Brian Dean wrote:
> OK, I did that. What is the convention for naming the flags? The
> only one in use for that set of flags is FP_SOFTFP. I'm currently
> using PCB_DBREGS, but I but I easily change the name to whatever
> convention dictates - please advise.
Jonathan Lemon writes:
> In article
> you write:
> >This is not as efficent as it could be implemented with a separate
> >flag to indicate whether saving the debug registers is necessary since
> >loading/storing the debug registers is fairly expensive (11 clocks on
> >an i486).
>
> Yes; you may
Jonathan Lemon writes:
> In article [EMAIL PROTECTED]> you
>write:
> >This is not as efficent as it could be implemented with a separate
> >flag to indicate whether saving the debug registers is necessary since
> >loading/storing the debug registers is fairly expensive (11 clocks on
> >an i486).
:(which hopefully constitute the bulk of the system load.) As a rough
:guide as to what's up for grabs, Liedtke's measured a reduction of the
:cost of a context switch on L4 from somewhere between 95 and 914 clocks
:(on pentium) down to 23 clock cycles when using small address spaces.
:The performa
> I've got some prototype code in place which supports the context
> switching part of this. It's pretty simple right now, as I'm trying
> to keep changes to a minimum.
>
> What I've done is simply added the dr0-dr3,dr6,dr7 registers to
> 'struct pcb' in /usr/src/sys/i386/include/pcb.h. In cpu_
:(which hopefully constitute the bulk of the system load.) As a rough
:guide as to what's up for grabs, Liedtke's measured a reduction of the
:cost of a context switch on L4 from somewhere between 95 and 914 clocks
:(on pentium) down to 23 clock cycles when using small address spaces.
:The perform
> I've got some prototype code in place which supports the context
> switching part of this. It's pretty simple right now, as I'm trying
> to keep changes to a minimum.
>
> What I've done is simply added the dr0-dr3,dr6,dr7 registers to
> 'struct pcb' in /usr/src/sys/i386/include/pcb.h. In cpu
In article yo
u write:
>This is not as efficent as it could be implemented with a separate
>flag to indicate whether saving the debug registers is necessary since
>loading/storing the debug registers is fairly expensive (11 clocks on
>an i486).
Yes; you may want to just use another bit in pcb_fl
In article [EMAIL PROTECTED]> yo
u write:
>This is not as efficent as it could be implemented with a separate
>flag to indicate whether saving the debug registers is necessary since
>loading/storing the debug registers is fairly expensive (11 clocks on
>an i486).
Yes; you may want to just use an
hink the changes to gdb would be minimal. It already
supports hardware debug support. We'd just need to hook in our
facility for setting/getting the hardware watchpoints at the
apropriate place(s).
Thanks,
-Brian
--
Brian Dean SAS Institute Inc brd...@unx.sas.com
>
hink the changes to gdb would be minimal. It already
supports hardware debug support. We'd just need to hook in our
facility for setting/getting the hardware watchpoints at the
apropriate place(s).
Thanks,
-Brian
--
Brian Dean SAS Institute Inc [EMAIL PROTECTED]
> T
On Saturday, 3 July 1999 at 12:13:55 -0400, Brian F. Feldman wrote:
> On Sat, 3 Jul 1999, Peter Wemm wrote:
>
>> Thomas David Rivers wrote:
Is there any interest in supporting something like this in FreeBSD?
I'm volunteering to spend some cycles on this, but I don't want to go
On Saturday, 3 July 1999 at 12:13:55 -0400, Brian F. Feldman wrote:
> On Sat, 3 Jul 1999, Peter Wemm wrote:
>
>> Thomas David Rivers wrote:
Is there any interest in supporting something like this in FreeBSD?
I'm volunteering to spend some cycles on this, but I don't want to go
On Sat, 3 Jul 1999, Peter Wemm wrote:
> Thomas David Rivers wrote:
> > >
> > > Is there any interest in supporting something like this in FreeBSD?
> > > I'm volunteering to spend some cycles on this, but I don't want to go
> > > to the effort if there's little chance that the work would be
> > >
On Sat, 3 Jul 1999, Peter Wemm wrote:
> Thomas David Rivers wrote:
> > >
> > > Is there any interest in supporting something like this in FreeBSD?
> > > I'm volunteering to spend some cycles on this, but I don't want to go
> > > to the effort if there's little chance that the work would be
> > >
Thomas David Rivers wrote:
> >
> > Hi,
> >
> > After recently debugging a very elusive memory overwrite problem that
> > I was only able to find by setting up a debugger watch point, and
> > suffering through the slowness that this introduced, I began reading
> > up on the ix86 support for hardw
Thomas David Rivers wrote:
> >
> > Hi,
> >
> > After recently debugging a very elusive memory overwrite problem that
> > I was only able to find by setting up a debugger watch point, and
> > suffering through the slowness that this introduced, I began reading
> > up on the ix86 support for hardwa
>
> Hi,
>
> After recently debugging a very elusive memory overwrite problem that
> I was only able to find by setting up a debugger watch point, and
> suffering through the slowness that this introduced, I began reading
> up on the ix86 support for hardware watch points. Using this facility
>
>
> Hi,
>
> After recently debugging a very elusive memory overwrite problem that
> I was only able to find by setting up a debugger watch point, and
> suffering through the slowness that this introduced, I began reading
> up on the ix86 support for hardware watch points. Using this facility
> o
Hi,
After recently debugging a very elusive memory overwrite problem that
I was only able to find by setting up a debugger watch point, and
suffering through the slowness that this introduced, I began reading
up on the ix86 support for hardware watch points. Using this facility
of the chip would
Hi,
After recently debugging a very elusive memory overwrite problem that
I was only able to find by setting up a debugger watch point, and
suffering through the slowness that this introduced, I began reading
up on the ix86 support for hardware watch points. Using this facility
of the chip would
30 matches
Mail list logo
