"Brent W. Baccala" writes:
> On Wed, Nov 23, 2016 at 10:03 PM, Brent W. Baccala
> wrote:
>
>>
>> Any comments?
>>
>
> Well, yes, actually. :-)
>
> gdb's hurd target has a poorly documented command "set noninvasive". I
> don't completely understand it, but...
gdb in noninvasive mode does not s
On Wed, Nov 23, 2016 at 10:03 PM, Brent W. Baccala
wrote:
>
> Any comments?
>
Well, yes, actually. :-)
gdb's hurd target has a poorly documented command "set noninvasive". I
don't completely understand it, but...
I'm starting to see the rational for an "invasive" debugging mode.
"Invasive" m
On Wed, 2016-11-23 at 22:03 -1000, Brent W. Baccala wrote:
> Hi -
>
> I've been working with gdb on the test programs that Samuel posted to
> test signal preemptors.
>
> It seems that gdb doesn't reliably intercept the task's exception
> port. It intercepts it once, when it creates the child pro
Hi -
I've been working with gdb on the test programs that Samuel posted to test
signal preemptors.
It seems that gdb doesn't reliably intercept the task's exception port. It
intercepts it once, when it creates the child process, but then assumes
that it doesn't change. Something else, I think _
Hello,
Brent W. Baccala, on Sun 20 Nov 2016 22:03:51 -1000, wrote:
> Obviously, tacking a Mach-specific include into signals.c isn't the right
> solution, so can somebody suggest a proper fix?
Better ask a gdb list :)
Samuel
Hi -
I've been trying to use gdb on ext2fs when it runs out of disk space and
starts generating memory access exceptions.
It doesn't behave right. The memory faults get reported as unknown signals
and the program can't be restarted:
Program received signal ?, Unknown signal.
[Switching to Threa
