Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
	tromey@redhat.com, 	gdb-patches@sourceware.org
Subject: Re: [FYI] Inlining support, rough patch
Date: Sat, 27 Jun 2009 18:01:00 -0000	[thread overview]
Message-ID: <20090627180122.GA6139@caradoc.them.org> (raw)
In-Reply-To: <20090420155405.GA6072@host0.dyn.jankratochvil.net>

On Mon, Apr 20, 2009 at 05:54:05PM +0200, Jan Kratochvil wrote:
> On Mon, 20 Apr 2009 17:49:09 +0200, Daniel Jacobowitz wrote:
> > Nothing algorithmic has changed,
> > but we have a few bug fixes and improved testcases.
> 
> 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

Thanks for the link.  Some of these I've already got fixes for.
For instance, the changes in breakpoint.c about returning from a
function to an inlined frame; I fixed it somewhere else, but we
did discover that problem.

Others, particularly the testsuite changes, I don't understand.  I'd
need to see a compiler that failed to work out why the changes were
needed.  So if you still need patches after the latest version of the
patch is checked in, please let me know and I'll reproduce the
failures.

current_pc_is_notcurrent is interesting.  Do I have the scenario
right?

  * 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.

I merged the read_type_die fix, thanks.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2009-06-27 18:01 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 [this message]
2009-06-28 10:16                     ` Jan Kratochvil
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=20090627180122.GA6139@caradoc.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --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