[PATCH] gdb: use gdb_test_multiple in gdb_breakpoint
Pedro Alves
pedro@palves.net
Wed Jan 11 19:05:18 GMT 2023
On 2023-01-10 8:42 p.m., Simon Marchi wrote:
> On 1/10/23 14:56, Pedro Alves wrote:
>>
>> I think the intention of not issuing PASS by default, was that you can
>> use gdb_breakpoint to implement other procedures inside lib/gdb.exp.
>> If gdb_breakpoint starts issuing a PASS, then an implementation detail
>> of such procedures starts being visible, by ending up with two PASSes for
>> each call of the procedure that happens to use gdb_breakpoint, one for
>> gdb_breakpoint, and one for the caller procedure proper.
>
> And do you think this is important? Personally, I don't think the
> multiple PASSes is a problem.
As mentioned, this is more of a generic concern of all procedures exposed
by lib/gdb.exp. gdb_breakpoint was just one among many. Seems better to look
at the overall design/direction rather than just one case in isolation.
Let's take runto. It calls gdb_breakpoint (which used to use gdb_expect before your change),
and then gdb_run_cmd, and then gdb_expect directly. gdb_run_cmd itself uses gdb_expect.
gdb_run_cmd may use gdb_reload, which calls gdb_load, which uses gdb_load_cmd, which uses
gdb_expect.
So changing any of these gdb_expect to gdb_test_multiple would result in intermediate PASSes
starting to be emitted. Depending on refactoring, etc, you'd get different internal PASSes.
Depending on different target, you'd get wildly different internal PASSes, etc. You'd get
a lot more mismatching PASS/FAIL cases when one of the internal gdb_test_multiple's failed.
Etc. That doesn't seem like the ideal approach to me.
More information about the Gdb-patches
mailing list