This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Add a 'starti' command.
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