Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: lin zuojian <manjian2006@gmail.com>
To: Joel Brobecker <brobecker@adacore.com>,
	Doug Evans <xdje42@gmail.com>,
	 "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Tom Tromey <tromey@redhat.com>, linzj <linzj@ucweb.com>
Subject: Re: PING: [PATCH v4] fixed inherit_abstract_dies infinite recursive call
Date: Thu, 13 Feb 2014 08:01:00 -0000	[thread overview]
Message-ID: <52FC7BC8.2010400@gmail.com> (raw)
In-Reply-To: <20140213073112.GS5485@adacore.com>

Hi Joel,
I am not really familiar with these routines,please help me with that.
Thank you.
(I carelessly used the company email in the last reply,sorry).

> Hi Doug,
>
>> Hi.  Thanks very much for the testcase!
> You are very welcome. Surprisingly, it took me a 2-3 hours to reduce
> it down. I tried using the DWARF assembler, but to no avail, so had
> to work from an asm file instead. We might be able to reproduce
> that asm file using the DWARF assembler, but I don't want to spend
> any more time on the testcase, unless I really have to.
>
>> I don't have much experience with abstract_origin.  I've read what I
>> can from DWARF4.pdf.
>> I can imagine that the bug is really in inherit_abstract_dies, and
>> thus the check to avoid re-processing the die belongs there.
>> Then we could maybe assert-fail in process_die if it's already being
>> processed.
> Same here.
>
>> E.g., where inherit_abstract_dies has this:
>>
>>             /* Found that ORIGIN_CHILD_DIE is really not referenced.  */
>>             process_die (origin_child_die, origin_cu);
>>
>> add a check for origin_child_die->in_process here, and only call
>> process_die if it's zero,
>> and add a comment saying the check is to avoid the case of mutually
>> referenced abstract_origins.
>> And include a reference to a bug number because for me one high order
>> bit here is finding the testcase that exercises this check.
>>
>> And then in process_die add at the start:
>>
>>   gdb_assert (!die->in_process);
>>
>> I don't have a strong opinion on which way to go though.
>> I *do* have a strong opinion on understanding *why* the code is
>> checking die->in_process.
>> If we go with the current patch, which is fine with me, though I'm
>> slightly leading towards the above instead but am happy to defer to
>> others, then I would replace this part of your patch:
>>
>> +  /* Only process those not already in process.  */
>> +  if (die->in_process)
>> +    return;
>>
>> with:
>>
>> +  /* Only process those not already in process.  PR 12345.  */
>> +  if (die->in_process)
>> +    return;
>>
>> And in either case file a bug that includes a description of the
>> problem (obviously :-)) and a reference to the testcase name.
>>
>> Thoughts?
> I agree with your all you suggestions.
>
> manjian2006@gmail.com, do you want to take care of this, or would you
> like me to? This involves first creating a PR, change your patch
> according to Doug's suggestion, re-test, and re-submit.
>


  reply	other threads:[~2014-02-13  8:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22  7:07 manjian2006
2014-01-28 12:06 ` Joel Brobecker
2014-02-10 14:28   ` PING: " Joel Brobecker
2014-02-10 17:37     ` Doug Evans
2014-02-11  2:19       ` Joel Brobecker
2014-02-12  6:58         ` Doug Evans
2014-02-13  7:31           ` Joel Brobecker
2014-02-13  8:01             ` lin zuojian [this message]
2014-02-14  3:34               ` Joel Brobecker
2014-02-19  6:48                 ` Doug Evans
2014-02-19  7:00                   ` lin zuojian
2014-02-19  7:59                   ` Joel Brobecker
2014-02-20 17:18                     ` Doug Evans
2014-02-20 17:48                       ` Joel Brobecker
2014-02-12  1:29     ` manjian2006

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=52FC7BC8.2010400@gmail.com \
    --to=manjian2006@gmail.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=linzj@ucweb.com \
    --cc=tromey@redhat.com \
    --cc=xdje42@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