Hi Samuel!
On Wed, 17 Sep 2014 01:17:06 +0200, Samuel Thibault
wrote:
> Thomas Schwinge, le Tue 16 Sep 2014 10:59:47 +0200, a écrit :
> > On Tue, 16 Sep 2014 01:09:50 +0200, Samuel Thibault
> > wrote:
> > > Thomas Schwinge, le Tue 16 Sep 2014 00:08:01 +0200, a écrit :
> > > > Do you agree that
Samuel Thibault, le Wed 17 Sep 2014 01:17:06 +0200, a écrit :
> I believe this will be fine to only expose the known-to-be-safe
> information, and clean dr6:
(this is mostly what Linux is doing)
Samuel
Hello,
Thomas Schwinge, le Tue 16 Sep 2014 10:59:47 +0200, a écrit :
> On Tue, 16 Sep 2014 01:09:50 +0200, Samuel Thibault
> wrote:
> > Thomas Schwinge, le Tue 16 Sep 2014 00:08:01 +0200, a écrit :
> > > Do you agree that thread_get_state(i386_DEBUG_STATE) should be
> > > returning the actual DR
Hi Samuel!
On Tue, 16 Sep 2014 01:09:50 +0200, Samuel Thibault
wrote:
> Thomas Schwinge, le Tue 16 Sep 2014 00:08:01 +0200, a écrit :
> > Do you agree that thread_get_state(i386_DEBUG_STATE) should be
> > returning the actual DR6,
>
> Indeed.
>
> > and where in GNU Mach would we need to copy t
Thomas Schwinge, le Tue 16 Sep 2014 00:08:01 +0200, a écrit :
> Do you agree that thread_get_state(i386_DEBUG_STATE) should be
> returning the actual DR6,
Indeed.
> and where in GNU Mach would we need to copy the DR6
> register into the PCB?
it would be user_trap(), probably, in the T_DEBUG case
Hi Samuel!
On Fri, 12 Sep 2014 19:56:13 +0200, I wrote:
> Many thanks for persisting with this patch. The GDB testsuite shows a
> pretty good improvement! I'll try to assess the remaining issues
From a quick scan through the »FAIL:.*watch« matches, the following one
issue should be relevant for
> Seeing a submission to gdb getting stuck on missing line breaks got me
> a bit on my nerves. Fortunately it wasn't only about that, but also
> important changes, so I carried on, but having to resubmit only for
> missing spaces or new lines would have been really hard to me, since I
> don't reall
On Friday, September 12 2014, Samuel Thibault wrote:
> What may help in the process would be to have a script which checks for
> style. The Linux kernel's checkpatch.pl is a very good approach, since
> one can get to check one's own style quite thoroughly before submitting.
This has been discusse
Joel Brobecker, le Fri 12 Sep 2014 13:01:41 -0700, a écrit :
> > > Many thanks for persisting with this patch.
> >
> > I have to say I'm almost about to give up with submitting it.
>
> I would be very interested in hearing your honest feedback on this.
> I know it took a long time, and we're not
> > Many thanks for persisting with this patch.
>
> I have to say I'm almost about to give up with submitting it.
I would be very interested in hearing your honest feedback on this.
I know it took a long time, and we're not always very responsive,
but we try our best. If we could hear what made y
On Friday, September 12 2014, Samuel Thibault wrote:
> Well, hardware watchpoints are fully documented in info.
Yes, but I am not talking about writing documentation for GDB, I am
talking about writing a commit message :-).
>> Is it possible to submit a testcase for this as well? WDYT?
>
> AIUI
Thomas Schwinge, le Fri 12 Sep 2014 19:56:13 +0200, a écrit :
> Unless you have push access to sourceware (do you?),
I don't.
Samuel
Joel Brobecker, le Fri 12 Sep 2014 09:51:49 -0700, a écrit :
> You forgot the comment I made about having the function documented
> at only one location, and the contents of that documentat.
I didn't forgot, but apparently I completely mangled my patch, sorry
about that.
Samuel
Sergio Durigan Junior, le Wed 10 Sep 2014 19:22:56 -0400, a écrit :
> Thanks for the patch, Samuel. What do you think of writing a message
> explaining a bit more of this feature, for the sake of putting it in the
> commit message? Just thinking aloud here...
Well, hardware watchpoints are fully
Thomas Schwinge, le Fri 12 Sep 2014 19:56:13 +0200, a écrit :
> Unless you have push access to sourceware (do you?), I'll be happy to
> push this for you once the pending review comments have been addressed.
> I have just to contribute a small patch to add on top of yours (merge it
> in) to make it
Hi Samuel!
Many thanks for persisting with this patch. The GDB testsuite shows a
pretty good improvement! I'll try to assess the remaining issues, but
From a functional point of view that patch is much of an improvement
already.
Unless you have push access to sourceware (do you?), I'll be happy
> 2014-09-06 Samuel Thibault
>
> Add hardware watch support to gnu-i386 platform.
>
> * gdb/gdb/gnu-nat.c (inf_threads): New function.
> * gdb/gdb/gnu-nat.h (inf_threads_ftype): New type.
> (inf_threads): New declaration.
> * gdb/gdb/i386gnu-nat.c: Include "x86-na
On Wednesday, September 10 2014, Samuel Thibault wrote:
> 2014-09-06 Samuel Thibault
>
> Add hardware watch support to gnu-i386 platform.
>
> * gdb/gdb/gnu-nat.c (inf_threads): New function.
> * gdb/gdb/gnu-nat.h (inf_threads_ftype): New type.
> (inf_threads): New declar
2014-09-06 Samuel Thibault
Add hardware watch support to gnu-i386 platform.
* gdb/gdb/gnu-nat.c (inf_threads): New function.
* gdb/gdb/gnu-nat.h (inf_threads_ftype): New type.
(inf_threads): New declaration.
* gdb/gdb/i386gnu-nat.c: Include "x86-nat.h" a
19 matches
Mail list logo
