Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Pouget <kevin.pouget@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pedro@codesourcery.com, pmuldoon@redhat.com,
	gdb-patches@sourceware.org, 	tromey@redhat.com
Subject: Re: [RFC][Python] gdbpy_frame_stop_reason_string bug
Date: Tue, 25 Oct 2011 14:27:00 -0000	[thread overview]
Message-ID: <CAPftXUJ0xABKVu=NaLEffLe0a_jVfkyCh6yx_UfBrxLVyBXt0w@mail.gmail.com> (raw)
In-Reply-To: <E1RIg16-0003sn-2C@fencepost.gnu.org>

On Tue, Oct 25, 2011 at 2:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Kevin Pouget <kevin.pouget@gmail.com>
>> Date: Tue, 25 Oct 2011 09:20:19 +0200
>> Cc: pedro@codesourcery.com, pmuldoon@redhat.com, gdb-patches@sourceware.org,
>>       tromey@redhat.com
>>
>> >> +@item gdb.FRAME_UNWIND_FIRST_ERROR
>> >> +All the conditions after this alias are considered errors;
>> >
>> > Hmm...  This table is preceded by this text:
>> >
>> >  @defun Frame.unwind_stop_reason ()
>> >  Return an integer representing the reason why it's not possible to find
>> >  more frames toward the outermost frame.  Use
>> >  @code{gdb.frame_stop_reason_string} to convert the value returned by this
>> >  function to a string. The value can be one of:
>> >
>> > So "conditions after this alias" seems inappropriate in the list that
>> > follows, because we are not describing conditions or aliases.  Can you
>> > rephrase this to be consistent with the rest of the list.
>>
>> I'm not sure about you see wrong with "alias". We could replace it
>> with "reference" (like the & operator in C++, but also used in Python
>> and Java), but it sounds more or less the same to me.
>>
>> What do you think about:
>> "Stop reasons greater or equal to this value/alias/reference"
>
> Now that I understand the intent, I would suggest
>
>  Any stop reason greater or equal to this value indicates some kind
>  of error.  This special value facilitates writing code that tests
>  for errors in unwinding in a way that will work correctly even if
>  the list of the other values is modified in future @value{GDBN}
>  versions.  Using it, you could write:

yes, if you feel like it has to be explicited, it's better this way

@smallexample
reason = gdb.selected_frame().unwind_stop_reason ()
reason_str =  gdb.frame_stop_reason_string (reason)
if reason >=  gdb.FRAME_UNWIND_FIRST_ERROR:
    print "An error occured during the unwinding process: %s" % reason_str

@end smallexample
>
>> > And why is it important that the value is an alias for another?
>>
>> it's important because it's not a distinct value as the other ones, so
>> > frame_stop_reason_string(UNWIND_FIRST_ERROR) == frame_stop_reason_string(UNWIND_UNAVAILABLE)
>> is True, which might be counter-intuitive if you don't know that
>> UNWIND_FIRST_ERROR is an alias/reference
>
> I still don't see the importance, sorry.  Moreover, having this text
> means that we will need to update the manual each time the list of
> unwind reasons is modified, **which in a way works against this very
> feature.**

You're half right with this last sentence, but this Python value is
not here to ease *our* (GDB developers) lives, but rather for Python
developers.
this value is not meant to change very often (not to say almost
never), so I think it's not a big burden to change the documentation
as well when it happens.
The very reason why I wrote it is that I think it's useful for the
reader: when you look over this list, you can easily see what is a
normal reason for unwinders to stop, and what isn't (I think that not
so many people will actually have the chance to use it, but out of
curiosity, some people will want to read and understand it).


But that put aside, you're not convinced yet and I'm running short of
arguments ... Pedro, Tom, Phil, how do you see that ?


  reply	other threads:[~2011-10-25 12:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-12 14:02 Kevin Pouget
2011-10-12 14:33 ` Phil Muldoon
2011-10-12 14:52 ` Pedro Alves
2011-10-12 15:18   ` Kevin Pouget
2011-10-12 15:28     ` Phil Muldoon
2011-10-12 15:59       ` Pedro Alves
2011-10-12 17:07         ` Tom Tromey
2011-10-13 11:25           ` Kevin Pouget
2011-10-13 11:27             ` Kevin Pouget
2011-10-13 15:19               ` Pedro Alves
2011-10-14  8:18                 ` Kevin Pouget
2011-10-14 14:22                   ` Tom Tromey
2011-10-14 14:41                     ` Kevin Pouget
2011-10-14 15:00                       ` Pedro Alves
2011-10-17 10:31                         ` Kevin Pouget
2011-10-19 21:22                           ` Tom Tromey
2011-10-24 16:53                             ` Kevin Pouget
2011-10-25  0:59                               ` Eli Zaretskii
2011-10-25  8:31                                 ` Kevin Pouget
2011-10-25 12:49                                   ` Eli Zaretskii
2011-10-25 14:27                                     ` Kevin Pouget [this message]
2011-10-27 10:02                                       ` Kevin Pouget
2011-10-27 10:16                                         ` Eli Zaretskii
2011-10-27 12:11                                           ` Kevin Pouget
2011-10-12 15:31     ` Pedro Alves
2011-10-12 17:06     ` Tom Tromey
2011-10-12 17:00   ` Tom Tromey

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='CAPftXUJ0xABKVu=NaLEffLe0a_jVfkyCh6yx_UfBrxLVyBXt0w@mail.gmail.com' \
    --to=kevin.pouget@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    --cc=pmuldoon@redhat.com \
    --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