This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v9 11/29] record-btrace: optionally indent function call history
- From: Pedro Alves <palves at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: "jan dot kratochvil at redhat dot com" <jan dot kratochvil at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 20 Dec 2013 16:47:23 +0000
- Subject: Re: [PATCH v9 11/29] record-btrace: optionally indent function call history
- Authentication-results: sourceware.org; auth=none
- References: <1387471499-29444-1-git-send-email-markus dot t dot metzger at intel dot com> <1387471499-29444-12-git-send-email-markus dot t dot metzger at intel dot com> <52B339A6 dot 3050205 at redhat dot com> <A78C989F6D9628469189715575E55B230AA3B917 at IRSMSX104 dot ger dot corp dot intel dot com>
On 12/20/2013 12:53 PM, Metzger, Markus T wrote:
>> On 12/19/2013 04:44 PM, Markus Metzger wrote:
>>> Add a new modifier /c to the "record function-call-history" command to
>>> indent the function name based on its depth in the call stack.
>>>
>>> Also reorder the optional fields to have the indentation at the very
>> beginning.
>>> Prefix the insn range (/i modifier) with "inst ".
>>
>> I was a little surprised the manual didn't get an update for this one,
>> but I see an /i example is currently lacking. Can one use both
>> /i and /l at the same time ?
>
> Yes. Does this need to be documented explicitly?
I think it'd be nice.
>>> There is one known bug regarding indentation that results from the fact
>> that we
>>> have the current instruction already inside the branch trace. When the
>> current
>>> instruction is the first (and only) instruction in a function on the outermost
>>> level for which we have not seen the call, the indentation starts at level 1
>>> with 2 leading spaces.
>>
>> Hmm. Why are we adding known bugs? I'm not sure I understood it, but
>> from
>> your description it sounds like the condition should be detectable?
>
> Yes, it is detectable. You can't fix it up afterwards, though, so you need to
> check this when computing the trace for each instruction. I have not tried
> to fix it because I think you wouldn't even notice it in practice.
>
> The fix is relatively easy, so I added it and updated the tests. Looking back, I
> can't really say why I haven't just fixed it right away.
Alright, sounds great. Thanks for going the extra mile.
--
Pedro Alves