From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Pedro Alves <palves@redhat.com>, Joel Brobecker <brobecker@adacore.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v2 2/3] frame: use get_prev_frame_always in skip_tailcall_frames
Date: Mon, 15 Feb 2016 09:51:00 -0000 [thread overview]
Message-ID: <A78C989F6D9628469189715575E55B2333262BD3@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B233325FCA0@IRSMSX104.ger.corp.intel.com>
> -----Original Message-----
> From: Metzger, Markus T
> Sent: Tuesday, February 9, 2016 4:20 PM
> To: Pedro Alves <palves@redhat.com>; Joel Brobecker
> <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> Subject: RE: [PATCH v2 2/3] frame: use get_prev_frame_always in
> skip_tailcall_frames
> > > I'm beginning to wonder if not all-but-the-backtrace-command-related
> > > get_prev_frame calls should really be calling get_prev_frame_always.
> > >
> > > The _always extension isn't very intuitive, though, given that this
> > > should be the standard function to use. Should get_prev_frame maybe
> > > be renamed to something like get_prev_frame_within_limit and
> > > get_prev_frame_always to get_prev_frame?
> >
> > Maybe a good idea. See also:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=15558
> >
> > I just noticed/remembered something -- the check for backtracing past
> > main and the entry point is in get_prev_frame, get_prev_frame_always
> > bypasses it.
> >
> > This means that with your change, I think gdb now allows "finish" in
> > "main" or in "_start".
> >
> > Maybe not a bad change, but I though it'd call it out explicitly.
>
> There are 46 calls to get_prev_frame ignoring this patch. Each of them
> should maybe be modified to call get_prev_frame_always, instead. And
> none of this is currently covered by the test suite.
I'm wondering in which cases GDB should ignore the user-defined backtrace
limit. And if GDB should ignore it at all.
If the limit is set, some aspects of GDB may not function any longer. But that's
to be expected, isn't it?
GDB shouldn't crash, of course. But I'm not sure if it should ignore user settings
in too many cases. Maybe we should even switch back to get_prev_frame in
skip_artificial_frames and rely on handling the NULL return if we exceed the
backtrace limit?
Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2016-02-15 9:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 14:18 [PATCH v2 1/3] frame: add skip_tailcall_frames Markus Metzger
2016-02-05 14:18 ` [PATCH v2 2/3] frame: use get_prev_frame_always in skip_tailcall_frames Markus Metzger
2016-02-07 13:01 ` Joel Brobecker
2016-02-08 8:14 ` Metzger, Markus T
2016-02-09 11:42 ` Pedro Alves
2016-02-09 11:58 ` Joel Brobecker
2016-02-09 14:25 ` Metzger, Markus T
2016-02-09 14:41 ` Pedro Alves
[not found] ` <A78C989F6D9628469189715575E55B233325FCA0@IRSMSX104.ger.corp.intel.com>
2016-02-15 9:51 ` Metzger, Markus T [this message]
2016-02-17 15:32 ` Pedro Alves
2016-02-19 11:36 ` Metzger, Markus T
2016-02-09 14:44 ` Joel Brobecker
2016-02-05 14:19 ` [PATCH v2 3/3] btrace, frame: fix crash in get_frame_type Markus Metzger
2016-02-09 12:05 ` Pedro Alves
2016-02-09 14:43 ` Metzger, Markus T
2016-02-09 22:01 ` Pedro Alves
2016-02-10 7:40 ` Metzger, Markus T
2016-02-10 9:59 ` Pedro Alves
2016-02-10 10:29 ` Metzger, Markus T
2016-02-10 15:02 ` Metzger, Markus T
2016-02-10 15:34 ` Pedro Alves
2016-02-11 9:51 ` Metzger, Markus T
2016-02-11 13:39 ` Pedro Alves
2016-02-11 15:42 ` Metzger, Markus T
2016-02-11 15:58 ` Pedro Alves
2016-02-11 16:07 ` Metzger, Markus T
2016-02-07 13:00 ` [PATCH v2 1/3] frame: add skip_tailcall_frames Joel Brobecker
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=A78C989F6D9628469189715575E55B2333262BD3@IRSMSX104.ger.corp.intel.com \
--to=markus.t.metzger@intel.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/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