From: Pedro Alves <palves@redhat.com>
To: John Baldwin <jhb@FreeBSD.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Add a 'starti' command.
Date: Thu, 31 Aug 2017 21:51:00 -0000 [thread overview]
Message-ID: <645c49bd-86fb-88c8-e22c-3613a72f2be7@redhat.com> (raw)
In-Reply-To: <20170829225457.66096-1-jhb@FreeBSD.org>
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 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.
- 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.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-08-31 21:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 22:55 John Baldwin
2017-08-30 14:14 ` Eli Zaretskii
2017-08-30 22:32 ` Keith Seitz
2017-08-31 21:51 ` Pedro Alves [this message]
2017-08-31 22:42 ` John Baldwin
2017-09-01 21:42 ` John Baldwin
2017-09-02 6:28 ` Ruslan Kabatsayev
2017-09-04 10:57 ` Pedro Alves
2017-09-11 22:08 ` John Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=645c49bd-86fb-88c8-e22c-3613a72f2be7@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox