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

[Ruslan Kabatsayev <b7.10110111@gmail.com>]

Hello John,

On 2 September 2017 at 00:42, John Baldwin <jhb@freebsd.org> 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 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.
>
Dunno if this helps, but you might want to check what happens inside GDB when
you start an inferior as

gdb -ex 'b *0' -ex run /path/to/program

In this case GDB fails to set the breakpoint (due to invalid access to
address 0x0),
and the `run` command stops exactly at the first instruction. If we
get `starti` to work
using a similar mechanism, I think it'd be just enough on the
implementation side,
no need for any "normal" breakpoints.

>> I agree with Keith - this should really have some tests.
>>
>> For example:
>>
>> - write a global constructor that sets a flag, and then check
>>   that the flag is still clear when we're still at the entry point.
>>   This can be either a C++ test or a C test using
>>   __attribute__ ((constructor))-
>>
>> - After creating the inferior, check that you can manually set
>>   a break on main, and continue to it.
>
> I've created a test which does these two (will send a v2 in a minute).
>
>> - Try backtrace, and check that only one frame comes
>>   out.  That may expose buggy unwinders that don't stop
>>   unwinding at the entry point currently, but then that
>>   should be fixed anyway, since users will run into that
>>   too.
>
> This one didn't work out for me on either FreeBSD or a CentOS 7 VM.  I
> know for the FreeBSD case the initial entry point in the runtime linker
> doesn't have any CFI directives that would aid in unwinding, and that
> might be true for ld.so on Linux as well.
>
> FreeBSD:
>
> (gdb) starti
> Starting program: /bin/ls
> Temporary breakpoint 1 at 0x800609650: file /usr/src/libexec/rtld-elf/amd64/rtld_start.S, line 33.
>
> Temporary breakpoint 1, .rtld_start ()
>     at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:33
> 33              xorq    %rbp,%rbp               # Clear frame pointer for good form
> (gdb) where
> #0  .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:33
> #1  0x0000000000000001 in ?? ()
> #2  0x00007fffffffe648 in ?? ()
> #3  0x0000000000000000 in ?? ()
>
> CentOS 7:
>
> (gdb) starti
> Starting program: /usr/bin/ls
> Temporary breakpoint 1 at 0x7ffff7ddd170
>
> Temporary breakpoint 1, 0x00007ffff7ddd170 in _start ()
>    from /lib64/ld-linux-x86-64.so.2
> (gdb) where
> #0  0x00007ffff7ddd170 in _start () from /lib64/ld-linux-x86-64.so.2
> #1  0x0000000000000001 in ?? ()
> #2  0x00007fffffffe6ac in ?? ()
> #3  0x0000000000000000 in ?? ()
>
> --
> John Baldwin

Regards,
Ruslan