Re: gdb(1) broken?
At 9:22 AM +0200 9/18/01, Mark Santcroos wrote: >Hi Peter, > >What is the state of this (for i386)? > >Mark > >On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote: >> Marcel Moolenaar wrote: >> > >> > Gang, >> > >> > I don't know exactly what the gdb(1) problems on Alpha are, but we >> > do have a problem that's probably not specific to an architecture. >> > >> > The problem is basicly this: one cannot debug any programs because >> > gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never >> > gets a change to wait4(2) the "interior" process. >> > >> > I don't know the details, but one of the following can be the case >> > 1. We now deliver a SIGTRAP, when we didn't do so before, >> > 2. The SIGTRAP comes too quick, it should be "caught" by the wait4(2). >> > >> > I couldn't find any indication that 1 happened, so my guess is that >> > we suffer from 2. >> > >> > Is this known? >> > Any thoughts? >> >> peter has been working on this... >> > > It's because the process structure and u-area have changed entirely. I just checked in a change to fix this problem (sys/kern/sys_process.c v1.71). The KSE changes caused the trace information to be put into the debug process state instead of the traced process. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb(1) broken?
Hi Peter, What is the state of this (for i386)? Mark On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote: > Marcel Moolenaar wrote: > > > > Gang, > > > > I don't know exactly what the gdb(1) problems on Alpha are, but we > > do have a problem that's probably not specific to an architecture. > > > > The problem is basicly this: one cannot debug any programs because > > gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never > > gets a change to wait4(2) the "interior" process. > > > > I don't know the details, but one of the following can be the case > > 1. We now deliver a SIGTRAP, when we didn't do so before, > > 2. The SIGTRAP comes too quick, it should be "caught" by the wait4(2). > > > > I couldn't find any indication that 1 happened, so my guess is that > > we suffer from 2. > > > > Is this known? > > Any thoughts? > > peter has been working on this... > > It's because the process structure and u-area have changed entirely. > > > > > > -- > > Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > -- > ++ __ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > | ( OZ)\___ ___ | country ! > +- X_.---._/presently in San Francisco \_/ \\ > v > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb(1) broken?
On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote: > > peter has been working on this... > > It's because the process structure and u-area have changed entirely. Hmmm... I can't explain the behaviour I see with this info. Can you explain why gdb(1) gets the SIGTRAP? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb(1) broken?
Marcel Moolenaar wrote: > > Gang, > > I don't know exactly what the gdb(1) problems on Alpha are, but we > do have a problem that's probably not specific to an architecture. > > The problem is basicly this: one cannot debug any programs because > gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never > gets a change to wait4(2) the "interior" process. > > I don't know the details, but one of the following can be the case > 1. We now deliver a SIGTRAP, when we didn't do so before, > 2. The SIGTRAP comes too quick, it should be "caught" by the wait4(2). > > I couldn't find any indication that 1 happened, so my guess is that > we suffer from 2. > > Is this known? > Any thoughts? peter has been working on this... It's because the process structure and u-area have changed entirely. > > -- > Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gdb(1) broken?
Gang, I don't know exactly what the gdb(1) problems on Alpha are, but we do have a problem that's probably not specific to an architecture. The problem is basicly this: one cannot debug any programs because gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never gets a change to wait4(2) the "interior" process. I don't know the details, but one of the following can be the case 1. We now deliver a SIGTRAP, when we didn't do so before, 2. The SIGTRAP comes too quick, it should be "caught" by the wait4(2). I couldn't find any indication that 1 happened, so my guess is that we suffer from 2. Is this known? Any thoughts? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
