Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?

[Pedro Alves <palves at redhat dot com>]

On 12/12/2013 05:25 PM, Pedro Alves wrote:
> On 12/02/2013 04:10 PM, Tom Tromey wrote:
>>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>>
>> Pedro> I'd assume scripts just check the result of Frame.unwind_stop_reason,
>> Pedro> and compare it to gdb.FRAME_UNWIND_NO_REASON.  That at most, they'll
>> Pedro> pass the result of Frame.unwind_stop_reason to
>> Pedro> gdb.frame_stop_reason_string.  I'd prefer to just get rid of it, but
>> Pedro> it may be best to keep this around for compatibility, in case a script
>> Pedro> does refer to gdb.FRAME_UNWIND_NULL_ID directly.
>>
>> Pedro> In general, what's the policy for exposed constants like this in
>> Pedro> Python?
>>
>> My view is that we should provide compatibility with what we document.
>>
>> That is, if it is in the docs, we should not remove it.
>>
>> However, there is still some leeway for change.
>> E.g., in this case, we don't document the value or type of the constant.
>> This is intentional as it gives us some freedom to change the details --
>> we don't generally want Python API promises to leak through to the C
>> code.
>>
>> Pedro> +/* This is no longer used anywhere, but it's kept because it's exposed
>> Pedro> +   to Python.  This is how GDB used to indicate end of stack.  We've
>> Pedro> +   now migrated to a model where frames always have a valid ID.  */
>> Pedro>  SET (UNWIND_NULL_ID, "unwinder did not report frame ID")
>>  
>> For example you could remove this, and arrange to keep the Python
>> constant around with some suitably chosen value.  I think it just has to
>> be something that will never compare equal to any of the other
>> constants, so just None would work.
> 
> I tried that, and then I remembered to try frame_stop_reason_string
> on it:
> 
> (top-gdb) python print gdb.FRAME_UNWIND_NULL_ID
> None
> (top-gdb) python print gdb.FRAME_UNWIND_OUTERMOST
> 1
> (top-gdb) python print gdb.frame_stop_reason_string(gdb.FRAME_UNWIND_OUTERMOST)
> outermost
> (top-gdb) python print gdb.frame_stop_reason_string(gdb.FRAME_UNWIND_NULL_ID)
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> TypeError: an integer is required
> Error while executing Python code.
> 
> GDB itself won't ever generate FRAME_UNWIND_NULL_ID.  Do think
> that's a problem? I guess we could set it to UNWIND_LAST+1
> instead, and make gdbpy_frame_stop_reason_string handle it,
> but at that point, I get to consider just leaving things
> alone...
> 
> Hmm, or perhaps, we could implement this another way.  Leave
> UNWIND_NULL_ID in unwind_stop_reasons.def, but define it
> with a DEPRECATED_SET macro instead.  I guess that might
> actually be better considering multiple extension languages
> going forward, as then we have a single place to do this,
> instead of having to repeat the "create deprecated constant"
> exercise for all extension languages whenever something like
> this happens.

Well, I tried that, but the result doesn't look that
much better to me.  I'm not really motivated to handle
this right now, so I'll just forget about it for now.
(others do please feel free to carry on.  I do believe
we'll end up needing to set some precedent.)

-- 
Pedro Alves