Re: [PATCH] Add a 'starti' command.

[John Baldwin <jhb@freebsd.org>]

On Monday, September 04, 2017 11:57:26 AM Pedro Alves wrote:
> 
> On 09/01/2017 10:42 PM, John Baldwin wrote:
> > On Thursday, August 31, 2017 11:51:33 PM Pedro Alves wrote:
> >> Hi John,
> >>
> >> On 08/30/2017 12:54 AM, John Baldwin wrote:
> >>> This works like 'start' but it stops at the first instruction rather than
> >>> the first line in main().  This is useful if one wants to single step
> >>> through runtime linker startup.
> >>
> >> I like the idea.  I actually once wrote a patch quite similar to this.
> >> I had called the command "create", inspired by "target_create_inferior".
> >> Is there a reason to actually set a breakpoint at the first instruction and
> >> run to it, actually?  My old prototype just created the inferior and
> >> didn't resume it all, see:
> >>
> >>  https://github.com/palves/gdb/commits/create_command
> >>
> >> though maybe going through normal_stop may be a good idea.
> 
> I should expand on this sentence above.  I was thinking of thinks like,
> should a user-defined hook-stop run in this case?  Probably.  Going
> via "normal_stop" makes sure that is handled.  My old prototype would
> skip any hook-stop (and I don't recall whether I did that on purpose.)
> 
> This suggests to me that it'd be good to have a test making sure
> we either run the hook-stop or not, whatever we decide should happen.

Ok, I included hook-stop in my test.

> > I tried this today and ended up with gdb hung in poll() but not printing a
> > prompt or accepting commands still, so I've left it as a breakpoint.
> 
> Another option is still go via process/normal_stop, but make sure that
> the thread won't really be run by queing a pending status.  Like so:
> 
>   if (/* starti mode*/)
>     {
>       // queue a pending event instead of setting a breakpoint at "*$pc".
>       thread_info *thr = inferior_thread ();
>       thr->suspend.waitstatus_pending_p = 1;
>       thr->suspend.waitstatus.kind = TARGET_WAITKIND_STOPPED;
>       thr->suspend.waitstatus.value.sig = GDB_SIGNAL_0;
>     }

Yes, I like this and have adopted it.

> One difference this makes is that this way the inferior doesn't really
> ever get a chance to run.  If a signal in nostop+pass state is queued
> between creating the process and running to the breakpoint at "*$pc",
> the signal handler (if any), runs.  With the pending event approach,
> it won't.

Technically I don't think a program can register a signal handler without
executing an instruction, but I think the above approach is cleaner
regardless.

-- 
John Baldwin