[Bug python/12175] show_doc for gdb.Parameter has strange behaviour

["pedro at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12175

--- Comment #5 from Pedro Alves <pedro at codesourcery dot com> 2010-11-16 15:30:13 UTC ---
(In reply to comment #4)
> Yeah, we can.  

> First we would have to identify the parameter as being written
> in Python.  

I don't think you need this.  Looking at py-param.c:add_setshow_generic,
you're currently always passing NULL as both set_func and show_func callbacks.
I'd like to make this illegal at some point.  You'd instead pass a pointer to
py-param.c specific callbacks, and then these new callbacks' implementation
would know to call the corresponding callback on the Python (language) side.
As a first step, this can be make optional, with the current behavior as
fallback, of course.

> Then we would require the user to implement show/set documentation
> functions in Python.  

At some point, yes.  With i18n, it's necessary.  As a first step,
we should at least add the possibility to implement the callback.
This callback is also the way some commands can show the
"(currently foo)" part: As I understand it, it's not possible do
have a param do that in python currently.  E.g.,:

 (gdb) show breakpoint always-inserted 
 Always inserted breakpoint mode is auto (currently off).

> Then, when the value printing/help parameter code
> sections are executed in GDB we can check if it is a Python scripted parameter,
> and if so then call into the Python object where it would return the
> appropriate string for the above functions.

Well, no need for the generic code to know this is a python parameter ---
the generic code just calls the installed callback through a function pointer
as usual.  But instead of getting the default callback implementation
(cli/cli-setshow.c:deprecated_show_value_hack), it'd call a new
python/py-param.c:py_show_param_value function.

> 
> This would be an API regression on our part though. We might be able to do this
> generically which would avoid requiring parameter API changes, but not sure
> how.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.