| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In a different series I tweak how disabled_by_cond is handled in
update_breakpoint_locations for code_breakpoint objects, see:
https://inbox.sourceware.org/gdb-patches/cover.1734366277.git.aburgess@redhat.com
But when I did this I ran into a regression in the test script
gdb.base/condbreak-multi-context.cc which I think is actually an issue
with this test.
The test relies on creating a multi-location breakpoint with a
condition and having GDB disable some of the locations as the
condition is only valid in some of the locations.
Here's an example of the test creating one such breakpoint:
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context...
(gdb) break func if a == 10
warning: failed to validate condition at location 1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 3, disabling:
No symbol "a" in current context.
Breakpoint 1 at 0x401142: func. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23
1.2 y 0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31
1.3 N* 0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
(gdb)
Notice that only location 1.2 is actually enabled, 1.1 and 1.3 are
disabled due to the condition 'a == 10' not being valid.
However, notice that this b/p is created before GDB has started the
inferior. What I noticed is that if I first start the inferior then I
get a different behaviour:
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context...
(gdb) start
Temporary breakpoint 1 at 0x40110e: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc, line 49.
Starting program: /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context
Temporary breakpoint 1, main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:49
49 aobj.func ();
(gdb) break func if a == 10
Breakpoint 2 at 0x401142: func. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
stop only if a == 10
2.1 y 0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23
2.2 y 0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31
2.3 y 0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39
(gdb)
Notice that now all three locations are valid.
What's actually happening is that, on my machine libm.so contains a
global symbol 'a' which for 2.1 and 2.3 is being used to satisfy the
condition.
I don't believe this is actually the intention of the test, this is
just an unfortunate consequence of name collision.
The test actually relies on the local variables 'a' and 'c', and my
libm.so contains a global version of both.
So I propose that we just update the test, I've gone for the super
inventive 'aaa' and 'ccc'. With this change, after starting the
inferior I now see the expected behaviour where only one of the three
locations is enabled.
However, while I'm fixing this I figure that it would be nice if the
test checked both cases, creating the breakpoints before starting the
inferior, and after starting the inferior.
So I've updated the test to check both cases. This has meant
converting the mostly linear test script into a set of parameterised
functions which I then call with a flag to indicate if the inferior
should be started before of after creating the breakpoints.
Approved-By: Tom Tromey <tom@tromey.com>
Tested-By: Hannes Domani <ssbssa@yahoo.de>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
With gcc 4.8.5, I run into:
...
Running gdb.base/condbreak-multi-context.exp ...
gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \
data member initializers only available with -std=c++11 or -std=gnu++11 \
[enabled by default]
int b = 20;
^
...
Fix this by making it a static const.
Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
Currently, for a conditional breakpoint, GDB checks if the condition
can be evaluated in the context of the first symtab and line (SAL).
In case of an error, defining the conditional breakpoint is aborted.
This prevents having a conditional breakpoint whose condition may
actually be meaningful for some of the location contexts. This patch
makes it possible to define conditional BPs by checking all location
contexts. If the condition is meaningful for even one context, the
breakpoint is defined. The locations for which the condition gives
errors are disabled.
The bp_location struct is introduced a new field, 'disabled_by_cond'.
This field denotes whether the location is disabled automatically
because the condition was non-evaluatable. Disabled-by-cond locations
cannot be enabled by the user. But locations that are not
disabled-by-cond can be enabled/disabled by the user manually as
before.
For a concrete example, consider 3 contexts of a function 'func'.
class Base
{
public:
int b = 20;
void func () {}
};
class A : public Base
{
public:
int a = 10;
void func () {}
};
class C : public Base
{
public:
int c = 30;
void func () {}
};
Note that
* the variable 'a' is defined only in the context of A::func.
* the variable 'c' is defined only in the context of C::func.
* the variable 'b' is defined in all the three contexts.
With the existing GDB, it's not possible to define a conditional
breakpoint at 'func' if the condition refers to 'a' or 'c':
(gdb) break func if a == 10
No symbol "a" in current context.
(gdb) break func if c == 30
No symbol "c" in current context.
(gdb) info breakpoints
No breakpoints or watchpoints.
With this patch, it becomes possible:
(gdb) break func if a == 10
warning: failed to validate condition at location 1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 3, disabling:
No symbol "a" in current context.
Breakpoint 1 at 0x11b6: func. (3 locations)
(gdb) break func if c == 30
Note: breakpoint 1 also set at pc 0x11ce.
Note: breakpoint 1 also set at pc 0x11c2.
Note: breakpoint 1 also set at pc 0x11b6.
warning: failed to validate condition at location 1, disabling:
No symbol "c" in current context.
warning: failed to validate condition at location 2, disabling:
No symbol "c" in current context.
Breakpoint 2 at 0x11b6: func. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
2 breakpoint keep y <MULTIPLE>
stop only if c == 30
2.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
2.2 N* 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
2.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
Here, uppercase 'N' denotes that the location is disabled because of
the invalid condition, as mentioned with a footnote in the legend of
the table. Locations that are disabled by the user are still denoted
with lowercase 'n'. Executing the code hits the breakpoints 1.2 and
2.3 as expected.
Defining a condition on an unconditional breakpoint gives the same
behavior above:
(gdb) break func
Breakpoint 1 at 0x11b6: func. (3 locations)
(gdb) cond 1 a == 10
warning: failed to validate condition at location 1.1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 1.3, disabling:
No symbol "a" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
Locations that are disabled because of a condition cannot be enabled
by the user:
...
(gdb) enable 1.1
Breakpoint 1's condition is invalid at location 1, cannot enable.
Resetting the condition enables the locations back:
...
(gdb) cond 1
Breakpoint 1's condition is now valid at location 1, enabling.
Breakpoint 1's condition is now valid at location 3, enabling.
Breakpoint 1 now unconditional.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
If a location is disabled by the user, a condition can still be defined
but the location will remain disabled even if the condition is meaningful
for the disabled location:
...
(gdb) disable 1.2
(gdb) cond 1 a == 10
warning: failed to validate condition at location 1.1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 1.3, disabling:
No symbol "a" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 n 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
The condition of a breakpoint can be changed. Locations'
enable/disable states are updated accordingly.
...
(gdb) cond 1 c == 30
warning: failed to validate condition at location 1.1, disabling:
No symbol "c" in current context.
Breakpoint 1's condition is now valid at location 3, enabling.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if c == 30
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 N* 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
(gdb) cond 1 b == 20
Breakpoint 1's condition is now valid at location 1, enabling.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if b == 20
1.1 y 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 n 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
# Note that location 1.2 was disabled by the user previously.
If the condition expression is bad for all the locations, it will be
rejected.
(gdb) cond 1 garbage
No symbol "garbage" in current context.
For conditions that are invalid or valid for all the locations of a
breakpoint, the existing behavior is preserved.
Regression-tested on X86_64 Linux.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (class bp_location) <disabled_by_cond>: New field.
* breakpoint.c (set_breakpoint_location_condition): New function.
(set_breakpoint_condition): Disable a breakpoint location if parsing
the condition string gives an error.
(should_be_inserted): Update to consider the 'disabled_by_cond' field.
(build_target_condition_list): Ditto.
(build_target_command_list): Ditto.
(build_bpstat_chain): Ditto.
(print_one_breakpoint_location): Ditto.
(print_one_breakpoint): Ditto.
(breakpoint_1): Ditto.
(bp_location::bp_location): Ditto.
(locations_are_equal): Ditto.
(update_breakpoint_locations): Ditto.
(enable_disable_bp_num_loc): Ditto.
(init_breakpoint_sal): Use set_breakpoint_location_condition.
(find_condition_and_thread_for_sals): New static function.
(create_breakpoint): Call find_condition_and_thread_for_sals.
(location_to_sals): Call find_condition_and_thread_for_sals instead
of find_condition_and_thread.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.cc: New file.
* gdb.base/condbreak-multi-context.exp: New file.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document disabling of breakpoint
locations for which the breakpoint condition is invalid.
|
