python API to trigger a "select-frame" like event with a given location

python API to trigger a "select-frame" like event with a given location

[Simon Sobisch via Gdb]

using a frame filter and decorator I can drop "not interesting" frames 
and add "artificial - display only" ones:


Instead of

(gdb) backtrace

#0  PROG2_ (...) at copybook.cpy:14
#1  PROG2 (...) at progb.cob:127
#2  PROG1_ (...) at init.cpy:21
#3  PROG1 (...) at prog.cob:139
#4  main  (...) at prog.c:23223

I can show (combined with

(gdb) mybacktrace

#0  PROG2_ (...) at copybook.cpy:14
#0.0  COPYFUNC SECTION at copybook.cpy:14
#0.1  PROGFIN SECTION at progb.cob:521
#0.2  PROGMAIN SECTION at progb.cob:195
#0.3  PROG2 at progb.cob:127
#2  PROG1_ (...) at init.cpy:21
#2.0  PROG-INIT-EXT SECTION at init.cpy:21
#2.1  PROG-INIT SECTION at init.cpy:41
#2.2  MAIN-000 SECTION at proga.cob:139
#2.3  PROG1 at proga.cob:139


Also there's the option to add myup and mydown commands which select the 
"expected" frame (0 and 2, in this example) where all the relevant 
variables are defined.


But currently I see no way to programmatically "select" by location 
(frame + linespec/LOCATION) [which would, other than "list" also be 
passed to UIs/MI).

Is there an option that I've overlooked?


If not: could there be an extension to "select-frame level"

select-frame level LOCATION

select-frame level -- Select a stack frame by level and show LOCATION in
                       the UI

or a new command

show-location LOCATION

that executes what select-frame does, but _without_ selecting anything 
(calling interps_notify() with the location as "selection")?


Thanks for any insights and for possibly considering this feature request.

Simon

Re: python API to trigger a "select-frame" like event with a given location

[Andrew Burgess via Gdb]

Simon Sobisch via Gdb <gdb@sourceware.org> writes:

> using a frame filter and decorator I can drop "not interesting" frames 
> and add "artificial - display only" ones:
>
>
> Instead of
>
> (gdb) backtrace
>
> #0  PROG2_ (...) at copybook.cpy:14
> #1  PROG2 (...) at progb.cob:127
> #2  PROG1_ (...) at init.cpy:21
> #3  PROG1 (...) at prog.cob:139
> #4  main  (...) at prog.c:23223
>
> I can show (combined with
>
> (gdb) mybacktrace
>
> #0  PROG2_ (...) at copybook.cpy:14
> #0.0  COPYFUNC SECTION at copybook.cpy:14
> #0.1  PROGFIN SECTION at progb.cob:521
> #0.2  PROGMAIN SECTION at progb.cob:195
> #0.3  PROG2 at progb.cob:127
> #2  PROG1_ (...) at init.cpy:21
> #2.0  PROG-INIT-EXT SECTION at init.cpy:21
> #2.1  PROG-INIT SECTION at init.cpy:41
> #2.2  MAIN-000 SECTION at proga.cob:139
> #2.3  PROG1 at proga.cob:139
>
>
> Also there's the option to add myup and mydown commands which select the 
> "expected" frame (0 and 2, in this example) where all the relevant 
> variables are defined.
>
>
> But currently I see no way to programmatically "select" by location 
> (frame + linespec/LOCATION) [which would, other than "list" also be 
> passed to UIs/MI).
>
> Is there an option that I've overlooked?
>
>
> If not: could there be an extension to "select-frame level"
>
> select-frame level LOCATION
>
> select-frame level -- Select a stack frame by level and show LOCATION in
>                        the UI
>
> or a new command
>
> show-location LOCATION
>
> that executes what select-frame does, but _without_ selecting anything 
> (calling interps_notify() with the location as "selection")?

If I understand what you need, then you are looking for way to implement
your 'myup' and 'mydown' commands such that GDB will appear to move
though the artificial frames (e.g. 0.0, 0.1, 0.2, 0.3, etc).  To do this
you need to select the real frame (#0), but then want some way such that
GDB will notify the various UI's to indicate that their focus should
shift to the source locations corresponding to the artificial frames,
right?

You mention, but seem to dismiss, using 'list'.  Can you expand on why
this doesn't meet your needs?

Which UIs in particular is it that you are interested in seeing update?
I ask because I'm wondering which events it is that would need to be
emitted.  Could you expand with some user stories, which UI is the user
looking at, what actions do they perform, and what is updated as a
consequence.

Thanks,
Andrew

Re: python API to trigger a "select-frame" like event with a given location

[Simon Sobisch via Gdb]

Am 30.09.2025 um 17:30 schrieb Andrew Burgess:
> Simon Sobisch via Gdb <gdb@sourceware.org> writes:
> 
>> using a frame filter and decorator I can drop "not interesting" frames
>> and add "artificial - display only" ones:
>>
>>
>> Instead of
>>
>> (gdb) backtrace
>>
>> #0  PROG2_ (...) at copybook.cpy:14
>> #1  PROG2 (...) at progb.cob:127
>> #2  PROG1_ (...) at init.cpy:21
>> #3  PROG1 (...) at prog.cob:139
>> #4  main  (...) at prog.c:23223
>>
>> I can show (combined with
>>
>> (gdb) mybacktrace
>>
>> #0  PROG2_ (...) at copybook.cpy:14
>> #0.0  COPYFUNC SECTION at copybook.cpy:14
>> #0.1  PROGFIN SECTION at progb.cob:521
>> #0.2  PROGMAIN SECTION at progb.cob:195
>> #0.3  PROG2 at progb.cob:127
>> #2  PROG1_ (...) at init.cpy:21
>> #2.0  PROG-INIT-EXT SECTION at init.cpy:21
>> #2.1  PROG-INIT SECTION at init.cpy:41
>> #2.2  MAIN-000 SECTION at proga.cob:139
>> #2.3  PROG1 at proga.cob:139
>>
>>
>> Also there's the option to add myup and mydown commands which select the
>> "expected" frame (0 and 2, in this example) where all the relevant
>> variables are defined.
>>
>>
>> But currently I see no way to programmatically "select" by location
>> (frame + linespec/LOCATION) [which would, other than "list" also be
>> passed to UIs/MI).
>>
>> Is there an option that I've overlooked?
>>
>>
>> If not: could there be an extension to "select-frame level"
>>
>> select-frame level LOCATION
>>
>> select-frame level -- Select a stack frame by level and show LOCATION in
>>                         the UI
>>
>> or a new command
>>
>> show-location LOCATION
>>
>> that executes what select-frame does, but _without_ selecting anything
>> (calling interps_notify() with the location as "selection")?
> 
> If I understand what you need, then you are looking for way to implement
> your 'myup' and 'mydown' commands such that GDB will appear to move
> though the artificial frames (e.g. 0.0, 0.1, 0.2, 0.3, etc).  To do this
> you need to select the real frame (#0), but then want some way such that
> GDB will notify the various UI's to indicate that their focus should
> shift to the source locations corresponding to the artificial frames,
> right?

Exactly

> You mention, but seem to dismiss, using 'list'.  Can you expand on why
> this doesn't meet your needs?

Because "list" sends no events, so registered mi clients (Emacs, vim, 
fancy-ide-of-your-choice) have no info on that.

> Which UIs in particular is it that you are interested in seeing update?
> I ask because I'm wondering which events it is that would need to be
> emitted.  Could you expand with some user stories, which UI is the user
> looking at, what actions do they perform, and what is updated as a
> consequence.

Likely "list" will also not apply to TUI's assembly window, which 
handles "up" and "down" just fine - so that would be another one.

> Thanks,
> Andrew

Thanks for taking the time to read and answer in the first place!
Simon

Re: python API to trigger a "select-frame" like event with a given location

[Tom Tromey]

>>>>> "Andrew" == Andrew Burgess via Gdb <gdb@sourceware.org> writes:

>> If not: could there be an extension to "select-frame level"
>> 
>> select-frame level LOCATION
>> 
>> select-frame level -- Select a stack frame by level and show LOCATION in
>> the UI
>> 
>> or a new command
>> 
>> show-location LOCATION
>> 
>> that executes what select-frame does, but _without_ selecting anything 
>> (calling interps_notify() with the location as "selection")?

Andrew> If I understand what you need, then you are looking for way to implement
Andrew> your 'myup' and 'mydown' commands such that GDB will appear to move
Andrew> though the artificial frames (e.g. 0.0, 0.1, 0.2, 0.3, etc).  To do this
Andrew> you need to select the real frame (#0), but then want some way such that
Andrew> GDB will notify the various UI's to indicate that their focus should
Andrew> shift to the source locations corresponding to the artificial frames,
Andrew> right?

Andrew> You mention, but seem to dismiss, using 'list'.  Can you expand on why
Andrew> this doesn't meet your needs?

Andrew> Which UIs in particular is it that you are interested in seeing update?
Andrew> I ask because I'm wondering which events it is that would need to be
Andrew> emitted.  Could you expand with some user stories, which UI is the user
Andrew> looking at, what actions do they perform, and what is updated as a
Andrew> consequence.

FWIW there was some discussion of some related ideas in

https://sourceware.org/bugzilla/show_bug.cgi?id=18567

My view is that it would be good to have more features in this area, and
that the main barrier is just implementing them, with maybe the main
secondary problem being having convenient ways to turn them off.

thanks,
Tom

Re: python API to trigger a "select-frame" like event with a given location

[Andrew Burgess via Gdb]

Simon Sobisch <simonsobisch@gnu.org> writes:

> Am 30.09.2025 um 17:30 schrieb Andrew Burgess:
>> Simon Sobisch via Gdb <gdb@sourceware.org> writes:
>> 
>>> using a frame filter and decorator I can drop "not interesting" frames
>>> and add "artificial - display only" ones:
>>>
>>>
>>> Instead of
>>>
>>> (gdb) backtrace
>>>
>>> #0  PROG2_ (...) at copybook.cpy:14
>>> #1  PROG2 (...) at progb.cob:127
>>> #2  PROG1_ (...) at init.cpy:21
>>> #3  PROG1 (...) at prog.cob:139
>>> #4  main  (...) at prog.c:23223
>>>
>>> I can show (combined with
>>>
>>> (gdb) mybacktrace
>>>
>>> #0  PROG2_ (...) at copybook.cpy:14
>>> #0.0  COPYFUNC SECTION at copybook.cpy:14
>>> #0.1  PROGFIN SECTION at progb.cob:521
>>> #0.2  PROGMAIN SECTION at progb.cob:195
>>> #0.3  PROG2 at progb.cob:127
>>> #2  PROG1_ (...) at init.cpy:21
>>> #2.0  PROG-INIT-EXT SECTION at init.cpy:21
>>> #2.1  PROG-INIT SECTION at init.cpy:41
>>> #2.2  MAIN-000 SECTION at proga.cob:139
>>> #2.3  PROG1 at proga.cob:139
>>>
>>>
>>> Also there's the option to add myup and mydown commands which select the
>>> "expected" frame (0 and 2, in this example) where all the relevant
>>> variables are defined.
>>>
>>>
>>> But currently I see no way to programmatically "select" by location
>>> (frame + linespec/LOCATION) [which would, other than "list" also be
>>> passed to UIs/MI).
>>>
>>> Is there an option that I've overlooked?
>>>
>>>
>>> If not: could there be an extension to "select-frame level"
>>>
>>> select-frame level LOCATION
>>>
>>> select-frame level -- Select a stack frame by level and show LOCATION in
>>>                         the UI
>>>
>>> or a new command
>>>
>>> show-location LOCATION
>>>
>>> that executes what select-frame does, but _without_ selecting anything
>>> (calling interps_notify() with the location as "selection")?
>> 
>> If I understand what you need, then you are looking for way to implement
>> your 'myup' and 'mydown' commands such that GDB will appear to move
>> though the artificial frames (e.g. 0.0, 0.1, 0.2, 0.3, etc).  To do this
>> you need to select the real frame (#0), but then want some way such that
>> GDB will notify the various UI's to indicate that their focus should
>> shift to the source locations corresponding to the artificial frames,
>> right?
>
> Exactly
>
>> You mention, but seem to dismiss, using 'list'.  Can you expand on why
>> this doesn't meet your needs?
>
> Because "list" sends no events, so registered mi clients (Emacs, vim, 
> fancy-ide-of-your-choice) have no info on that.
>
>> Which UIs in particular is it that you are interested in seeing update?
>> I ask because I'm wondering which events it is that would need to be
>> emitted.  Could you expand with some user stories, which UI is the user
>> looking at, what actions do they perform, and what is updated as a
>> consequence.
>
> Likely "list" will also not apply to TUI's assembly window, which 
> handles "up" and "down" just fine - so that would be another one.
>
>> Thanks,
>> Andrew
>
> Thanks for taking the time to read and answer in the first place!

Thanks for clarifying.

I read through the bug Tom linked[1], and it appears solving this might
be quite an involved problem.

Though this is the sort of thing that does interest me, I don't have
time to work on this at the moment.  I've added the bug to my
"interesting bug" backlog, so might get to it one day, if nobody else
does first.

Sorry I couldn't be more help.

Thanks,
Andrew


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=18567



> Simon