Hello!
On Mon, Oct 13, 2008 at 07:35:34PM +0100, Pedro Alves wrote:
> Thanks Thomas :-) One thing I asked myself was, if gnu-nat.c couldn't be
> using
> the port's id as thread ids instead of a locally auto-generated number. Maybe
> the thread id of the main thread would be preserved across exe
Hi, and sorry I didn't reply back sooner.
On Monday 13 October 2008 17:40:25, Ulrich Weigand wrote:
> Thomas Schwinge wrote:
>
> > Ha, I, myself, am the GDB guru here ;-)! I had a look at the log again,
> > experimented some more, and finally got it going with the following
> > patch. However,
Thomas Schwinge wrote:
> Ha, I, myself, am the GDB guru here ;-)! I had a look at the log again,
> experimented some more, and finally got it going with the following
> patch. However, I have absolutely no idea whether that is correct in all
> cases, etc. Should perhaps target_wait (a.k.a. gnu-
Hello!
On Sat, Oct 11, 2008 at 06:46:31PM +0100, Pedro Alves wrote:
> > STOPPED_BY_WATCHPOINT () = 0
> > infrun: context switch
> > infrun: Switching context from bogus thread id 1 to Thread 25830.3
>
> ^^
>
> This
On Saturday 11 October 2008 18:26:11, Thomas Schwinge wrote:
> > Doesn't resume the whole shell?
>
> But as I see things we always have ``non_stop == 0'' and thus
> ``resume_ptid = pid_to_ptid (-1)'', so that should be fine, isn't it?
>
Duh! Yes, of course.
> Here is a debugging-enabled run o
Hello again!
On Sat, Oct 11, 2008 at 07:26:11PM +0200, I wrote:
> Unfortunately no luck so far. wait_for_inferior / handle_inferior_event
> (which was used in the old code) is too complex as to be quickly
> understandable for me. And I guess I'm estimating correctly that it's
> ``simply'' some s
Hello!
On Sat, Oct 11, 2008 at 12:47:39AM +0100, Pedro Alves wrote:
> On Saturday 11 October 2008 00:27:06, Thomas Schwinge wrote:
> > On HEAD, when undoing this change (and additionally commenting out the
> > two ``stop_soon = X'' lines in that file), things are fine again.
At the end of this em
On Saturday 11 October 2008 00:27:06, Thomas Schwinge wrote:
> On HEAD, when undoing this change (and additionally commenting out the
> two ``stop_soon = X'' lines in that file), things are fine again.
>
> As most of GDB's internals are a big black box to me, I need help here.
> :-)
>
Eh, I did
Hello!
On Thu, Oct 09, 2008 at 12:55:16PM +0100, Pedro Alves wrote:
> A Thursday 09 October 2008 10:34:24, Thomas Schwinge escreveu:
> > Some of the changes that have been installed between gdb_6_8-branch and
> > HEAD cause GDB to no longer function properly on GNU/Hurd under certain
> > circumsta
A Thursday 09 October 2008 10:34:24, Thomas Schwinge escreveu:
> Hello!
>
> Some of the changes that have been installed between gdb_6_8-branch and
> HEAD cause GDB to no longer function properly on GNU/Hurd under certain
> circumstances.
>
> [EMAIL PROTECTED]:~/tmp/gdb/HEAD.build $ gdb/gdb
Hello!
Some of the changes that have been installed between gdb_6_8-branch and
HEAD cause GDB to no longer function properly on GNU/Hurd under certain
circumstances.
[EMAIL PROTECTED]:~/tmp/gdb/HEAD.build $ gdb/gdb ~/tmp/n1/hurd/ext2fs.static
GNU gdb 6.8.0.20081008-cvs
[...]
This
11 matches
Mail list logo
