Follow-fork-mode and inferiors

Follow-fork-mode and inferiors

[Kevin Pouget]

Hello,

I noticed a behavior which appears strange to me, I would like to know
if it was expected:

> (gdb) list
> 1    int main() {
> 2        fork() ;
> 3    }
>
> (gdb) break 3
> (gdb) set follow-fork-mode child
> (gdb) run
> ...
> Breakpoint 1, main () at fork.c:3
> 3    }
> (gdb) info inferiors
>   Num  Description       Executable
> * 2    process 26039     /home/kevin/travail/arm/perso/root/sample/fork-threads/fork
>   1    <null>            /home/kevin/travail/arm/perso/root/sample/fork-threads/fork

why are there two inferiors? I expected either to stay in inf 1 (if
the pid of an inferior can change) or inf 1 to disappear, but not to
keep both of them!

thanks,

Kevin

Re: Follow-fork-mode and inferiors

[Tom Tromey]

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Kevin> why are there two inferiors? I expected either to stay in inf 1
Kevin> (if the pid of an inferior can change) or inf 1 to disappear, but
Kevin> not to keep both of them!

I suspect that it may be due to your `follow-exec-mode' setting.
I am not really certain though.

Tom

Re: Follow-fork-mode and inferiors

[Kevin Pouget]

oh, I didn't now this  `follow-exec-mode' setting, which explains why
we might want to create a new inferior

but (as the name suggests) it's not involved when the inferior forks,
and GDB behaves as if it were set to 'new'. Unfortunately,
`follow-fork-mode' is already used to follow the child or the parent
...



Kevin
--

(gdb) help set follow-exec-mode
Set debugger response to a program call of exec.
An exec call replaces the program image of a process.

follow-exec-mode can be:

  new - the debugger creates a new inferior and rebinds the process
to this new inferior.  The program the process was running before
the exec call can be restarted afterwards by restarting the original
inferior.

  same - the debugger keeps the process bound to the same inferior.
The new executable image replaces the previous executable loaded in
the inferior.  Restarting the inferior after the exec call restarts
the executable the process was running after the exec call.

By default, the debugger will use the same inferior.

(gdb) help set follow-fork-mode
Set debugger response to a program call of fork or vfork.
A fork or vfork creates a new process.  follow-fork-mode can be:
  parent  - the original process is debugged after a fork
  child   - the new process is debugged after a fork
The unfollowed process will continue to run.
By default, the debugger will follow the parent process.

On Wed, Apr 13, 2011 at 10:29 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
>
> Kevin> why are there two inferiors? I expected either to stay in inf 1
> Kevin> (if the pid of an inferior can change) or inf 1 to disappear, but
> Kevin> not to keep both of them!
>
> I suspect that it may be due to your `follow-exec-mode' setting.
> I am not really certain though.
>
> Tom
>

Re: Follow-fork-mode and inferiors

[Pedro Alves]

On Wednesday 13 April 2011 14:33:01, Kevin Pouget wrote:
> Hello,
> 
> I noticed a behavior which appears strange to me, I would like to know
> if it was expected:
> 
> > (gdb) list
> > 1    int main() {
> > 2        fork() ;
> > 3    }
> >
> > (gdb) break 3
> > (gdb) set follow-fork-mode child
> > (gdb) run
> > ...
> > Breakpoint 1, main () at fork.c:3
> > 3    }
> > (gdb) info inferiors
> >   Num  Description       Executable
> > * 2    process 26039     /home/kevin/travail/arm/perso/root/sample/fork-threads/fork
> >   1    <null>            /home/kevin/travail/arm/perso/root/sample/fork-threads/fork
> 
> why are there two inferiors? I expected either to stay in inf 1 (if
> the pid of an inferior can change) or inf 1 to disappear, but not to
> keep both of them!

Hmm, if detach-on-fork is on (the default), yeah.
I'd argue for staying in inf 1.  linux-nat.c:linux_child_follow_fork
is the place to look.  The problem is the vfork case, and
what to do with the vfork parent.

-- 
Pedro Alves

GDB Darwin

[James Boulton]

Hi,

I'm trying to find a way to compile a remote debugger which supports an ARM 
Darwin target. The gdb server seems to work fine and I can remote debug 
using an ARM targetted GDB, but of course I cant read the symbols in as 
there is no support for the mach-o format with an ARM target.

I see GDB now has support for i386, x64 and PowerPC flavours of darwin, but 
not ARM. Is ARM Darwin support planned? I'm trying to find a nice way of 
debugging directly from a Windows machine (there is already an ARM Darwin 
targeted GDB, but this is only on OSX).

Thanks,
-- James 

Re: GDB Darwin

[Joel Brobecker]

> I see GDB now has support for i386, x64 and PowerPC flavours of
> darwin, but not ARM. Is ARM Darwin support planned? I'm trying to
> find a nice way of debugging directly from a Windows machine (there
> is already an ARM Darwin targeted GDB, but this is only on OSX).

As far as I know, I haven't heard of anyone planning on doing the work
for ARM.

-- 
Joel

Re: GDB Darwin

[James Boulton]

Are there any docs on where to start with something like this?

The BFD settings from Apples branch are all present in GDB 7.2 i.e.

  arm-*-darwin* | arm-*-macos10*)
    targ_defvec=mach_o_le_vec
    targ_selvecs="mach_o_be_vec mach_o_le_vec mach_o_fat_vec "
    targ_archs="bfd_arm_arch"
    targ_underscore=yes
    ;;

However building with that doesnt do anything useful.

How do you actually go about implementing a new target? Most of the 
functionality is present (mach-o, arm, darwin) but it needs glueing together 
correctly.

Thanks,
-- James


----- Original Message ----- 
From: "Joel Brobecker" <brobecker@adacore.com>
To: "James Boulton" <james.boulton@eiconic.com>
Cc: <gdb@sourceware.org>
Sent: Wednesday, June 01, 2011 5:22 PM
Subject: Re: GDB Darwin


>> I see GDB now has support for i386, x64 and PowerPC flavours of
>> darwin, but not ARM. Is ARM Darwin support planned? I'm trying to
>> find a nice way of debugging directly from a Windows machine (there
>> is already an ARM Darwin targeted GDB, but this is only on OSX).
>
> As far as I know, I haven't heard of anyone planning on doing the work
> for ARM.
>
> -- 
> Joel
> 

Re: GDB Darwin

[Thiago Jung Bauermann]

On Thu, 2011-06-02 at 14:02 +0100, James Boulton wrote:
> How do you actually go about implementing a new target? Most of the 
> functionality is present (mach-o, arm, darwin) but it needs glueing together 
> correctly.

You may find this document useful:

http://www.embecosm.com/appnotes/ean3/embecosm-howto-gdb-porting-ean3-issue-2.html

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center