RE: [PATCH 0/2] Breakpoint conditions at locations with differing contexts

Aktemur, Tankut Baris via Gdb-patches
2021-04-06T14:12:04Z

On Monday, April 5, 2021 7:46 PM, Jonah Graham wrote:
> On Fri, 31 Jul 2020 at 11:42, Tankut Baris Aktemur via Gdb-patches <mailto:gdb-patches@sourceware.org> wrote:
> > This is a short series about conditional breakpoints where the
> > condition may be invalid at some breakpoint locations because of their
> > context.
>
> Hi Tankut,
>
> I have been testing GDB master against current Eclipse CDT and I came across this change. I have some work in Eclipse CDT to display this information to the user which I am tracking in https://bugs.eclipse.org/bugs/show_bug.cgi?id=572589. Thanks for the new GDB feature!

Hi Jonah,

Thanks for the feedback and reporting this issue.

> 1. The problem I am having is that I want to display the "Breakpoint condition is invalid at this location" type info in the UI, but I can't see if there is any from MI to identify this information. Here is a trace that causes me a problem:
>
> $ ./gdb --interpreter=mi2 --quiet
> =thread-group-added,id="i1"
> (gdb)
> 18-file-exec-and-symbols --thread-group i1 /scratch/eclipse/src/cdt/runtime-CDT/bug572589/Debug/bug572589
> 18^done
> (gdb)
> 26-break-insert -c "invalid condition here" -f main
> &"warning: failed to validate condition at location 1, disabling:\n "
> &"No symbol \"invalid\" in current context.\n"
> 26^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="invalid condition here",times="0",original-location="main"},{number="1.1",enabled="N*",addr="0x0000000000001160",func="main",file="../src/bug572589.c",fullname="/scratch/eclipse/src/cdt/runtime-CDT/bug572589/src/bug572589.c",line="20",thread-groups=["i1"]}

This is an oversight. The expected behavior is that the breakpoint
is rejected here, because at no location the condition is valid and
the condition is not being explicitly forced.
So, the expected behavior is

(gdb)
-break-insert -c "invalid condition here" -f main
^error,msg="No symbol \"invalid\" in current context."

I'll submit a patch to fix it.

> (gdb)
> info break
> &"info break\n"
> ~"Num Type Disp Enb Address What\n"
> ~"1 breakpoint keep y <MULTIPLE> \n"
> ~"\tstop only if invalid condition here\n"
> ~"1.1 N* 0x0000000000001160 in main at ../src/bug572589.c:20\n"
> ~"(*): Breakpoint condition is invalid at this location.\n"
> ^done
> (gdb)
> 42-break-list
> 42^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="invalid condition here",times="0",original-location="main"},{number="1.1",enabled="N*",addr="0x0000000000001160",func="main",file="../src/bug572589.c",fullname="/scratch/eclipse/src/cdt/runtime-CDT/bug572589/src/bug572589.c",line="20",thread-groups=["i1"]}]}
> (gdb)
>
> Is the enabled="N*" what CDT can use to know that? https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html#GDB_002fMI-Breakpoint-Commands shows that enabled can be y or n (lowercase). If this is the way to identify the invalid condition, can this be documented explicitly in the docs?

"N*" is the third possible value and it means "disabled because the
condition is invalid at the location". I'll also submit a patch to
update the doc.

> Can the warning string be part of the breakpoint structure returned in MI?

Are you referring to the "warning: failed to validate condition
at location 1, disabling:" string? I'm not sure it should be a part
of the breakpoint structure. Wouldn't the 'N*' value suffice to give
the necessary information?

>
> 2. The other problem is I want to enable the -force-condition in the UI, but AFAICT that isn't supported from MI? If it is, I couldn't figure out the invocation that worked.

This flag does not exist. I'll submit a patch to recognize it in
the MI command.

>
> Any guidance you can provide is most welcome.
>
> Thanks,
> Jonah

Thanks.
-Baris

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928