Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb-patches@sourceware.org
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, Tom Tromey <tromey@redhat.com>
Subject: Re: [FYI] Inlining support, rough patch
Date: Sun, 28 Jun 2009 10:16:00 -0000	[thread overview]
Message-ID: <20090628101621.GA31457@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <20090627180122.GA6139@caradoc.them.org>

On Sat, 27 Jun 2009 20:01:22 +0200, Daniel Jacobowitz wrote:
> On Mon, Apr 20, 2009 at 05:54:05PM +0200, Jan Kratochvil wrote:
> > Fedora also has various fixes on top of it:
> > 	http://cvs.fedora.redhat.com/viewvc/rpms/gdb/devel/gdb-6.8-inlining-addon.patch?view=co
...
> Others, particularly the testsuite changes, I don't understand.

<smile>As I did not understand how the testsuites could work before</smile>
- it is clear it was due to some compiler differences.  I should retest the
changes against FSF GCC first, my only concern was Fedora GCC for that patch.


> current_pc_is_notcurrent is interesting.  Do I have the scenario
> right?

Yes, thanks for checking it (the changed testcases cover it somewhere).

>   * function() calls inlined() calls other()
>   * finish from other()
>   * show the end of inlined() instead of the next line of function()
> 
> I can't figure out if we should do this or not.  It does seem useful.
> But that's not where we are; we're showing the previous call site
> instead of the next instruction.
> 
> I think we should consider it as a general change for finish instead
> of specific to inlining.  The comments in your patch suggested that
> too.

My goal was to:
(1) Keep non-inlined GDB behavior the same.
(2) Keep the majority of inlined cases behavior the same as non-inlined one.

For FSF GDB we should break the rule (1).

(gdb) l
1	/* 1 */ int func (void) { return 1; }
2	/* 2 */ int main (void) { int x, y;
3	/* 3 */   func ();
4	/* 4 */   y = -1;
5	/* 5 */   x = func ();
6	/* 6 */   y = 1;
7	/* 7 */   return 0; }
Temporary breakpoint 1, main () at finish.c:3
3	/* 3 */   func ();

(gdb) step
func () at finish.c:1
1	/* 1 */ int func (void) { return 1; }
(gdb) finish
Run till exit from #0  func () at finish.c:1
main () at finish.c:4
4	/* 4 */   y = -1;
Value returned is $1 = 1
### Here `finish' is at the _next_ line of the call.  I would expect rather:
###	(gdb) finish
###	Run till exit from #0  func () at finish.c:1
###	main () at finish.c:4
###	3	/* 3 */   func ();
###	Value returned is $1 = 1
### Whether this or that case is shown is also dependent on the current
### architecture - currently the behavior differs depending of whether there
### is at least one instruction of the same source line after the call
### instruction.  Next `step' will have to do _nothing_ to the inferior, just
### display the next line in GDB.

(gdb) step
5	/* 5 */   x = func ();

(gdb) step
func () at finish.c:1
1	/* 1 */ int func (void) { return 1; }
(gdb) finish
Run till exit from #0  func () at finish.c:1
0x00000000004004a0 in main () at finish.c:5
5	/* 5 */   x = func ();
Value returned is $2 = 1

(gdb) step
6	/* 6 */   y = 1;
(gdb) 


TODOlisted to submit a patch for this behavior change of non-inlined functions
(which will cover even the inlined ones).


Thanks for the merge,
Jan


  reply	other threads:[~2009-06-28 10:16 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13 19:39 Daniel Jacobowitz
2008-06-13 19:43 ` Daniel Jacobowitz
2008-06-23 12:03 ` Jan Kratochvil
2008-06-23 14:23   ` Daniel Jacobowitz
2008-07-02 19:15   ` Daniel Jacobowitz
2008-07-03 11:22     ` [FYI] Inlining support, rough patch [break-by-function-name] Jan Kratochvil
2008-07-03 16:01       ` Daniel Jacobowitz
2008-07-12  7:41         ` Jan Kratochvil
2008-07-08  0:12     ` [FYI] Inlining support, rough patch Daniel Jacobowitz
2008-07-15 19:21 ` Daniel Jacobowitz
2008-07-17 23:53   ` Mark Kettenis
2008-07-18 13:03     ` Daniel Jacobowitz
     [not found]       ` <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl>
2008-07-25 17:47         ` Daniel Jacobowitz
2009-03-31  3:06           ` Tom Tromey
2009-03-31 20:49             ` Mark Kettenis
2009-03-31 22:13               ` Daniel Jacobowitz
2009-04-20 15:49               ` Daniel Jacobowitz
2009-04-20 15:54                 ` Jan Kratochvil
2009-06-27 18:01                   ` Daniel Jacobowitz
2009-06-28 10:16                     ` Jan Kratochvil [this message]
2009-06-28 13:35                       ` Daniel Jacobowitz
2009-06-30 16:11                       ` Tom Tromey
2009-06-30 16:50                         ` Jan Kratochvil
2009-04-22 22:04                 ` Mark Kettenis
2009-04-23  3:17                   ` Eli Zaretskii
2009-04-23  5:56                   ` Stan Shebs
2009-04-23 12:48                   ` Daniel Jacobowitz
2009-06-18 17:55                     ` Tom Tromey
2009-06-20  9:57                       ` Mark Kettenis
2009-06-20 19:28                         ` Samuel Bronson
2009-04-24 21:44                   ` Thiago Jung Bauermann
2008-07-18  2:02   ` Paul Pluzhnikov
2008-07-18  3:07     ` Daniel Jacobowitz
2008-07-20 14:41   ` Eli Zaretskii
2008-07-25 13:54   ` Eli Zaretskii
2008-07-25 14:26     ` Daniel Jacobowitz
2008-07-25 16:11       ` Daniel Jacobowitz
2008-07-26  5:58       ` Eli Zaretskii

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=20090628101621.GA31457@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=tromey@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