Get rid of ATTACH_NO_WAIT
Pedro Alves
pedro@codesourcery.com
Thu Jul 3 17:13:00 GMT 2008
Hi Joel,
A Thursday 03 July 2008 17:47:44, Joel Brobecker wrote:
> Hi Pedro,
>
> > 2008-06-28 Pedro Alves <pedro@codesourcery.com>
> >
> > * config/i386/nm-cygwin.h (ATTACH_NO_WAIT): Delete.
> > * config/i386/nm-i386gnu.h (ATTACH_NO_WAIT): Delete.
> >
> > * target.h (struct target_ops): Add to_attach_no_wait member.
> > (target_attach_no_wait): New.
> > * target.c (update_current_target): Inherit to_attach_no_wait.
> >
> > * infcmd.c: Replace ATTACH_NO_WAIT compile time check by
> > target_attach_no_wait runtime check.
> >
> > * gnu-nat.c (init_gnu_ops): Set to_attach_no_wait in gnu_ops.
> > * win32-nat.c (init_win32_ops): Set to_attach_no_wait in
> > win32_ops.
>
> I will be glad to see this macro go, and overall the patch looks good
> to me.
>
> One thing I had to think about a little was whether this property
> should be inherited or not (see target.c:update_current_target()).
> I'm still not sure, but I think it should.
I think it should. Normally, I expect the debug API to attach to a
process to be implemented by the process_stratum target, even if
the thread_stratum is pushed already for whatever reason, and needs
to do poke the just attached process.
> Imagine that we had
> a thread stratum on win32. Wouldn't you lose the attach_no_wait property
> when this thread stratum got pushed on the target? Until we find a
> target where the process and thread strata need a different setting,
> I think it's safer for now to make it inheritable. What do you think?
Hmm, I'm already doing it? Or did I miss anything?
--
Pedro Alves
More information about the Gdb-patches
mailing list