public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pierre-Marie de Rodat <derodat@adacore.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Eric Botcazou <ebotcazou@adacore.com>
Subject: Re: [PATCH] DWARF: add abstract origin links on lexical blocks DIEs
Date: Fri, 15 Jan 2016 14:41:00 -0000	[thread overview]
Message-ID: <56990512.7070808@adacore.com> (raw)
In-Reply-To: <CAFiYyc18OaWaSYB5SZTTUyoPT+ERD5rQ0aqnNdfqFOrT-QcgOw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

On 01/13/2016 01:17 PM, Richard Biener wrote:
> I wonder if you can construct a guality testcase that passes with and
> fails without
> the patch?

I’ve tried to first look at how guality testcases are written (thanks 
for your answers on IRC, by the way :-)) and then how I could write a 
testcase for my fix. It seems there are two ways: match patterns in the 
assembly file or evaluate an expression in GDB.

I already have the testcase I used during development: it’s written in 
Ada, to build with -O2. The way it checks the fix is to see if GDB 
manages to put a breakpoint on the Child2 symbol before executing the 
program (it cannot before my fix and it can afterwards). Oh, and it 
requires a fairly recent GDB version (7.10 looks good).

I managed to get a similar GNU C99 reproducer (it’s attached): the 
debugging information has the pattern that exhibits the bugfix. Namely: 
while the “parent” function is inlined, the “child” function (which is 
in a block inside “parent”) is not. So GDB relies on the 
DW_TAG_abstract_origin in the inlined block to refer to the abstract 
block that contains the DIE that materializes “child“.

However, it looks like there is no way in GDB to refer to C nested 
functions when they are not in the current scope:
> $ gcc -g -O2 -std=gnu99 nested_fun.c nested_fun_helpers.c
> $ gdb -n -q ./a.out
> (gdb) ptype child
> No symbol "child" in current context.
> (gdb) ptype nested_fun.parent.child
> No symbol "nested_fun" in current context.

On the other hand, this works with the Ada testcase:
> (gdb) ptype nested_fun.parent.child
> type = (false, true)

So I’m not sure what to do next: should I do a fragile testcase based on 
scanning the assembly file? (it could break with an optimizer change) 
create a guality testsuite for Ada?

> Anyway, the patch looks ok to me but please give others a chance to chime in.

Sure. Thank you for reviewing!

-- 
Pierre-Marie de Rodat

[-- Attachment #2: nested_fun.c --]
[-- Type: text/x-csrc, Size: 907 bytes --]

/* { dg-do run } */
/* { dg-options "-O2 -g -std=gnu99" } */

extern void *create (const char *);
extern void destroy (void *);
extern void do_nothing (char);

struct string
{
  const char *data;
  int lb;
  int ub;
};

int
main (void)
{
  void *o1 = create ("foo");

  void
  parent (void)
  {
    {
      void *o2 = create ("bar");

      int
      child (struct string s)
      {
	int i = s.lb;

	if (s.lb <= s.ub)
	  while (1)
	    {
	      char c = s.data[i - s.lb];
	      do_nothing (c);
	      if (c == 'o')
		return 1;
	      if (i == s.ub)
		break;
	      ++i;
	    }
	return 0;
      }

      int r;

      r = child ((struct string) {"baz", 1, 3});
      r = child ((struct string) {"qux", 2, 4});
      r = child ((struct string) {"foobar", 1, 6});
    }

    do_nothing (0);
  }

  /* { dg-final { gdb-test 56 "type:main::parent::child" "int (struct string)" } } */
  parent ();
  return 0;
}

[-- Attachment #3: nested_fun_helpers.c --]
[-- Type: text/x-csrc, Size: 124 bytes --]

void *
create (const char *s)
{
  return 0;
}

void
destroy (void *o)
{
  return;
}

void
do_nothing (char c)
{
  return;
}

  reply	other threads:[~2016-01-15 14:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-12 17:05 Pierre-Marie de Rodat
2016-01-13 12:17 ` Richard Biener
2016-01-15 14:41   ` Pierre-Marie de Rodat [this message]
2016-01-15 15:53     ` Richard Biener
2016-01-17 20:09       ` Eric Botcazou
2016-01-18  9:36         ` Richard Biener
2016-01-18  9:45           ` Eric Botcazou
2016-01-18  9:47             ` Pierre-Marie de Rodat
2016-01-20  9:47               ` Pierre-Marie de Rodat
2016-04-26  8:00                 ` [PING][PATCH] " Pierre-Marie de Rodat
2016-05-04 14:23                   ` [PING*2][PATCH] " Pierre-Marie de Rodat
2016-05-09 11:02                     ` Richard Biener
2016-05-10  8:04                       ` Pierre-Marie de Rodat

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=56990512.7070808@adacore.com \
    --to=derodat@adacore.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).