| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I hesitated between putting the file in the dwarf2 directory (as
gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h).
The concept of call site is not DWARF-specific, another debug info
reader could provide this information. But as it is, the implementation
is a bit DWARF-specific, as one form it can take is a DWARF expression
and parameters can be defined using a DWARF register number. So I ended up
choosing to put it under dwarf2/. If another debug info reader ever
wants to provide call site information, we can introduce a layer of
abstraction between the "common" call site and the "dwarf2" call site.
The copyright start year comes from the date `struct call_site` was
introduced.
Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
I want to move the call_site stuff out of gdbtypes.h, to a new header
file, to break some cyclic include problem. The call_site stuff uses
cu_offset, also defined in gdbtypes.h, so cu_offset also needs to move
somewhere else (otherwise, call-site.h will need to include gdbtypes.h,
and we are back to square 1). I could move cu_offset to the future new
file dwarf2/call-site.h, but it doesn't sound like a good place for it,
at cu_offset is not specific to call sites, it's used throughout
dwarf2/. So, move it to its own file, dwarf2/types.h. For now,
gdbtypes.h includes dwarf2/types.h, but that will be removed once the
call site stuff is moved to its own file.
Move sect_offset with it too. sect_offset is not a DWARF-specific
concept, but for the moment it is only used in dwarf2/.
Change-Id: I1fd2a3b7b67dee789c4874244b044bde7db43d8e
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This helps resolve some cyclic include problem later in the series.
The only language-related thing frame.h needs is enum language, and that
is in defs.h.
Doing so reveals that a bunch of files were relying on frame.h to
include language.h, so fix the fallouts here and there.
Change-Id: I178a7efec1953c2d088adb58483bade1f349b705
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
struct compile_instance needs to be visible to users, since we use
std::unique<compile_instance>. language.c and c-lang.c currently
includes compile-internal.h for this reason, which kind of defeats the
purpose of having an "internal" header file.
Change-Id: Iedffe5f1173b3de7bdc1be533ee2a68e6f6c549f
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
It's only used in compile/compile.c, it doesn't need to be in a header.
Change-Id: Ic5bec996b7b0cd7130055d1e8ff238b5ac4292a3
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
I noticed that pc_in_unmapped_range had a weird return type -- it was
returning a CORE_ADDR but intending to return a bool. This patch
changes all the pc_in_* functions to return bool instead.
|
|
It seems to me that a notif_client is read-only, so this patch changes
the code to use "const" everywhere.
|
|
I found this forward declaration for a struct that doesn't exist, remove
it.
Change-Id: Ib9473435a949452160598035e5e0fe19fcdc4d20
|
|
gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36.
However, it's actually generating the correct output -- it is just
that the test thinks that the "ptype" will not work because I do not
have the GNAT debuginfo installed.
This patch changes the code to accept either result, and then to issue
a kfail as appropriate.
|
|
When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the
`gnat-11` package installed (not `gnat`), with UBSan activated, I get:
(gdb) break foo.adb:40
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int'
The problematic DIEs are:
0x00001460: DW_TAG_subrange_type
DW_AT_lower_bound [DW_FORM_data1] (0x00)
DW_AT_upper_bound [DW_FORM_data16] (ffffffffffffffff3f00000000000000)
DW_AT_name [DW_FORM_strp] ("foo__packed_array___XP7___XDLU_0__1180591620717411303423")
DW_AT_type [DW_FORM_ref4] (0x0000153f "long_long_long_unsigned")
DW_AT_GNAT_descriptive_type [DW_FORM_ref4] (0x0000147e)
DW_AT_artificial [DW_FORM_flag_present] (true)
0x0000153f: DW_TAG_base_type
DW_AT_byte_size [DW_FORM_data1] (0x10)
DW_AT_encoding [DW_FORM_data1] (DW_ATE_unsigned)
DW_AT_name [DW_FORM_strp] ("long_long_long_unsigned")
DW_AT_artificial [DW_FORM_flag_present] (true)
When processed by this code:
negative_mask =
-((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
if (low.kind () == PROP_CONST
&& !base_type->is_unsigned () && (low.const_val () & negative_mask))
low.set_const_val (low.const_val () | negative_mask);
When the base type's length (16 bytes in this case) is larger than a
ULONGEST (typically 8 bytes), the bit shift is too large.
My obvious fix is just to skip the fixup for base types larger than a
ULONGEST (8 bytes). I don't think we really handle constant attribute
values larger than 8 bytes anyway, so this is part of a much larger
problem.
Add a test that replicates this situation, but uses bounds that fit in a
signed 64 bit, so we get a sensible result.
Change-Id: I8d0a24f3edd83b44e0761a0ce38922d3e2e112fb
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29386
|
|
I am looking at this code [1]:
/* Normally, the DWARF producers are expected to use a signed
constant form (Eg. DW_FORM_sdata) to express negative bounds.
But this is unfortunately not always the case, as witnessed
with GCC, for instance, where the ambiguous DW_FORM_dataN form
is used instead. To work around that ambiguity, we treat
the bounds as signed, and thus sign-extend their values, when
the base type is signed. */
negative_mask =
-((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
if (low.kind () == PROP_CONST
&& !base_type->is_unsigned () && (low.const_val () & negative_mask))
low.set_const_val (low.const_val () | negative_mask);
if (high.kind () == PROP_CONST
&& !base_type->is_unsigned () && (high.const_val () & negative_mask))
high.set_const_val (high.const_val () | negative_mask);
Nothing in the testsuite seems to exercise it, as when I remove it, all
of gdb.dwarf2 still passes. And tests in other directories would be
compiler-dependent, so would rely on having a buggy compiler.
Update gdb.dwarf2/subrange.exp to have a test for it. When removing the
code above, the new test fails with:
ptype array_with_buggy_negative_bounds_type^M
type = array [240..244] of signed_byte^M
(gdb) FAIL: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type
instead of the expected:
ptype array_with_buggy_negative_bounds_type^M
type = array [-16..-12] of signed_byte^M
(gdb) PASS: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type
[1] https://gitlab.com/gnutools/binutils-gdb/-/blob/5ea14aa4e53fa37f4ba4517497ed2c1e4c60dee2/gdb/dwarf2/read.c#L17681-17695
Change-Id: I1992a3ff0cb1e90fa8a9114dae6c591792f059c2
|
|
While looking at some test output, I saw that no-libstdcxx-probe.exp
was not being run. However, it occurred to me that Tom de Vries' new
"maint ignore-probes" command could be used to enable this test
unconditionally.
Reviewed-by: Tom de Vries <tdevries@suse.de>
|
|
Modify test cases that verify the operation of the array element limit
with character strings such that they are executed twice, once with the
`set print characters' option set to `elements' and the limit controlled
with the `set print elements' option, and then again with the limit
controlled with the `set print characters' option instead. Similarly
with the `-elements' and `-characters' options for the `print' command.
Additionally verify that said `print' command options combined yield the
expected result.
Verify correct $_gdb_setting and $_gdb_setting_str values for the `print
characters' setting, in particular the `void' value for the `elements'
default, which has no corresponding integer value exposed.
Add Guile and Python coverage for the `print characters' GDB setting.
There are new tests for Ada and Pascal, as the string printing code for
these languages is different than the generic string printing code used
by other languages. Modula2 also has different string printing code,
but (a) this is similar to Pascal, and (b) there are no existing modula2
tests written in Modula2, so I'm not sure how I'd even test the Modula2
string printing.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit splits the `set/show print elements' option into two. We
retain `set/show print elements' for controlling how many elements of an
array we print, but a new `set/show print characters' setting is added
which is used for controlling how many characters of a string are
printed.
The motivation behind this change is to allow users a finer level of
control over how data is printed, reflecting that, although strings can
be thought of as arrays of characters, users often want to treat these
two things differently.
For compatibility reasons by default the `set/show print characters'
option is set to `elements', which makes the limit for character strings
follow the setting of the `set/show print elements' option, as it used
to. Using `set print characters' with any other value makes the limit
independent from the `set/show print elements' setting, however it can
be restored to the default with the `set print characters elements'
command at any time.
A corresponding `-characters' option for the `print' command is added,
with the same semantics, i.e. one can use `elements' to make a given
`print' invocation follow the limit of elements, be it set with the
`-elements' option also given with the same invocation or taken from the
`set/show print elements' setting, for characters as well regardless of
the current setting of the `set/show print characters' option.
The GDB changes are all pretty straightforward, just changing references
to the old 'print_max' to use a new `get_print_max_chars' helper which
figures out which of the two of `print_max' and `print_max_chars' values
to use.
Likewise, the documentation is just updated to reference the new setting
where appropriate.
To make people's life easier the message shown by `show print elements'
now indicates if the setting also applies to character strings:
(gdb) set print characters elements
(gdb) show print elements
Limit on string chars or array elements to print is 200.
(gdb) set print characters unlimited
(gdb) show print elements
Limit on array elements to print is 200.
(gdb)
and the help text shows the dependency as well:
(gdb) help set print elements
Set limit on array elements to print.
"unlimited" causes there to be no limit.
This setting also applies to string chars when "print characters"
is set to "elements".
(gdb)
In the testsuite there are two minor updates, one to add `-characters'
to the list of completions now shown for the `print' command, and a bare
minimum pair of checks for the right handling of `set print characters'
and `show print characters', copied from the corresponding checks for
`set print elements' and `show print elements' respectively.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.
Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.
The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".
Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user. An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX. Such translation can now
be arbitrary. Literals defined by this structure are automatically used
for completion as necessary.
So for example:
const literal_def integer_unlimited_literals[] =
{
{ "unlimited", INT_MAX, 0 },
{ nullptr }
};
defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.
Similarly:
const literal_def zuinteger_unlimited_literals[] =
{
{ "unlimited", -1, -1 },
{ nullptr }
};
defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting. If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.
Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type. It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types. Similarly update the "must be >= -1" Guile error
message.
Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values. Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.
With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.
Update the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed a few spots that include gnu-stabs.h but that do not need
to. This patch removes these unnecessary includes. Tested by
rebuilding.
|
|
In aarch64-tdep.c we find these register aliases:
...
{
/* 64-bit register names. */
{"fp", AARCH64_FP_REGNUM},
{"lr", AARCH64_LR_REGNUM},
{"sp", AARCH64_SP_REGNUM},
...
The sp alias is superfluous, because the canonical name of x31 is already sp.
The fp alias is superfluous, because it's already taken by the default meaning
of fp, assigned here in _initialize_frame_reg:
...
user_reg_add_builtin ("fp", value_of_builtin_frame_fp_reg, NULL);
...
Fix this by removing the fp and sp aliases.
While we're at it, add an x31 alias for sp.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on aarch64-linux.
PR tdep/30012
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30012
|
|
On s390x-linux, I run into:
...
(gdb) python print(u[u_fields[0]])^M
99^M
(gdb) PASS: gdb.python/py-value-cc.exp: u's first field via field
python print(u[u_fields[1]])^M
0 '\000'^M
(gdb) FAIL: gdb.python/py-value-cc.exp: u's second field via field
...
There's a var u of this type:
...
union U {
int a;
char c;
};
...
and after assigning 99 to u.a, the test-case expects u.c to contain 99 (which
it does on x86_64), but instead it contains 0.
Fix this by instead assigning 0x63636363, to ensure that u.c == 99 for both
little and big endian.
Tested on x86_64-linux and s390x-linux.
|
|
Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct within
cmd_list_element") and commit 702991711a91 ("gdb: Have setter and getter
callbacks for settings") and update inline documentation accordingly for
`add_set_or_show_cmd' and `add_setshow_cmd_full_erased', documenting the
`args' parameter and removing references to `var', `set_setting_func'
and `get_setting_func'.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct
within cmd_list_element") and add missing description for
`add_setshow_cmd_full'.
|
|
Use proper English in the description of SET_LIST and SHOW_LIST.
|
|
Rename CLASS to THECLASS in the documentation for `theclass' parameters
throughout cli-decode.c, complementing commit fe978cb071b4 ("C++ keyword
cleanliness, mostly auto-generated").
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This reverts commit b22548ddb30bfb167708e82d3bb932461c1b703a.
This patch is being reverted since the patch series is causing regressions.
|
|
gdb.reverse/finish-reverse.exp"
This reverts commit 92e07580db6a5572573d5177ca23933064158f89.
Reverting patch as the patch series is causing regressions.
|
|
Accessing gdb.Objfile.build_id caused GDB to crash when objfile is
dynamic, that is created by JIT reader API.
The issue was NULL-pointer dereferencing in build_id_bfd_get () because
dynamic objfiles have no underlaying BFD structure. This commit fixes
the problem by a NULL-check in build_id_bfd_get ().
|
|
When I converted gdbarch to use the registry, I forgot to remove the
two fields that were used to implement the previous approach. This
patch removes them. Tested by rebuilding.
|
|
The new paramless.exp test was not converted to the new "require"
approach. This patch fixes the problem.
|
|
gdb.reverse/finish-reverse.exp
PR record/29927 - reverse-finish requires two reverse next instructions to
reach previous source line
PowerPC uses two entry points called the local entry point (LEP) and the
global entry point (GEP). Normally the LEP is used when calling a
function. However, if the table of contents (TOC) value in register 2 is
not valid the GEP is called to setup the TOC before execution continues at
the LEP. When executing in reverse, the function finish_backward sets the
break point at the alternate entry point (GEP). However if the forward
execution enters via the normal entry point (LEP), the reverse execution
never sees the break point at the GEP of the function. Reverse execution
continues until the next break point is encountered or the end of the
recorded log is reached causing gdb to stop at the wrong place.
This patch adds a new address to struct execution_control_state to hold the
address of the alternate function start address, known as the GEP on
PowerPC. The finish_backwards function is updated. If the stopping point
is between the two entry points (the LEP and GEP on PowerPC), the stepping
range is set to execute back to the alternate entry point (GEP on PowerPC).
Otherwise, a breakpoint is inserted at the normal entry point (LEP on
PowerPC).
Function process_event_stop_test checks uses a stepping range to stop
execution in the caller at the first instruction of the source code line.
Note, on systems that only support one entry point, the address of the two
entry points are the same.
Test finish-reverse-next.exp is updated to include tests for the
reverse-finish command when the function is entered via the normal entry
point (i.e. the LEP) and the alternate entry point (i.e. the GEP).
The patch has been tested on X86 and PowerPC with no regressions.
|
|
PR record/29927 - reverse-finish requires two reverse next instructions to
reach previous source line
Currently on X86, when executing the finish command in reverse, gdb does a
single step from the first instruction in the callee to get back to the
caller. GDB stops on the last instruction in the source code line where
the call was made. When stopped at the last instruction of the source code
line, a reverse next or step command will stop at the first instruction
of the same source code line thus requiring two step/next commands to
reach the previous source code line. It should only require one step/next
command to reach the previous source code line.
By contrast, a reverse next or step command from the first line in a
function stops at the first instruction in the source code line where the
call was made.
This patch fixes the reverse finish command so it will stop at the first
instruction of the source line where the function call was made. The
behavior on X86 for the reverse-finish command now matches doing a
reverse-next from the beginning of the function.
The proceed_to_finish flag in struct thread_control_state is no longer
used. This patch removes the declaration, initialization and setting of
the flag.
This patch requires a number of regression tests to be updated. Test
gdb.mi/mi-reverse.exp no longer needs to execute two steps to get to the
previous line. The gdb output for tests gdb.reverse/until-precsave.exp
and gdb.reverse/until-reverse.exp changed slightly. The expected result in
tests gdb.reverse/amd64-failcall-reverse.exp and
gdb.reverse/singlejmp-reverse.exp are updated to the correct expected
result.
This patch adds a new test gdb.reverse/finish-reverse-next.exp to test the
reverse-finish command when returning from the entry point and from the
body of the function.
The step_until proceedure in test gdb.reverse/step-indirect-call-thunk.exp
was moved to lib/gdb.exp and renamed cmd_until.
The patch has been tested on X86 and PowerPC to verify no additional
regression failures occured.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29927
|
|
When testing with the native-extended-gdbserver, I get:
Thread 1 "xgdb" received signal SIGSEGV, Segmentation fault.
0x00007ffff6d828f2 in GC_find_limit_with_bound () from /usr/lib/x86_64-linux-gnu/libgc.so.1
(gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt
This is because the -re that is supposed to match this SIGSEGV is after
`-i $inferior_spawn_id`. On native, the top and bottom GDB are on the
same spawn id, so it ends up working. But with a gdbserver board,
that's not the case. Move the SIGSEGV -re before the `-i
$inferior_spawn_id` line, such that it matches what the top GDB outputs.
Do the same fix in gdb.gdb/python-helper.exp.
Change-Id: I3291630e218a5a3a6a47805b999ddbc9b968c927
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR c++/29896 points out a regression in the new DWARF reader. It does
not properly handle a case like "break fn", where "fn" is a template
function.
This happens because the new index uses strncasecmp to compare.
However, to make this work correctly, we need a custom function that
ignores template parameters.
This patch adds a custom comparison function and fixes the bug. A new
test case is included.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896
|
|
I was briefly confused by the hash_entry and eq_entry functions in the
cooked index. They are only needed in a single method, and that
method already has a couple of local lambdas for a different hash
table. So, it seemed cleaner to move these there as well.
|
|
The DWARF reader has some code to remove empty indices. However, I
think this code has been obsolete since some earlier changes to
parallel_for_each. This patch removes this code.
|
|
I found that parallel_for_each would submit empty tasks to the thread
pool. For example, this can happen if the number of tasks is smaller
than the number of available threads. In the DWARF reader, this
resulted in the cooked index containing empty sub-indices. This patch
arranges to instead shrink the result vector and process the trailing
entries in the calling thread.
|
|
The test suite uses the --configuration flag to feature-test gdb.
However, when I added this, I neglected to pass the internal gdbflags
to this, causing an error, which then caused failures in the test
suite (which would not be seen if you'd ever run "make install").
This patch fixes the bug. Tested by removing my install tree first,
to verify that I could reproduce the failure.
|
|
This changes skip_tui_tests to invert the sense, and renames it to
allow_tui_tests. It also rewrites this function to use the output of
"gdb --configuration", and it adds a note about the state of the TUI
to that output.
|
|
This changes skip_guile_tests to invert the sense, and renames it to
allow_guile_tests. It also rewrites this proc to check the output of
"gdb --configuration", as was done for Python. Then it changes the
code to use "require" where possible.
|
|
This changes skip_hw_breakpoint_tests to invert the sense, and renames
it to allow_hw_breakpoint_tests. This also converts some tests to use
"require" -- I missed this particular check in the first series.
|
|
This changes skip_tsx_tests to invert the sense, and renames it to
allow_tsx_tests.
|
|
This changes skip_shlib_tests to invert the sense, and renames it to
allow_shlib_tests.
|
|
This changes skip_rust_tests to invert the sense, and renames it to
allow_rust_tests.
|
|
This changes skip_python_tests to invert the sense, and renames it to
allow_python_tests.
|
|
This changes skip_perf_tests to invert the sense, and renames it to
allow_perf_tests.
|
|
This changes skip_opencl_tests to invert the sense, and renames it to
allow_opencl_tests.
|
|
This changes skip_ifunc_tests to invert the sense, and renames it to
allow_ifunc_tests.
|
|
This changes skip_hw_watchpoint_tests to invert the sense, and renames
it to allow_hw_watchpoint_tests.
|
|
This changes skip_hw_watchpoint_multi_tests to invert the sense, and
renames it to allow_hw_watchpoint_multi_tests.
|
|
This changes skip_hw_watchpoint_access_tests to invert the sense, and
renames it to allow_hw_watchpoint_access_tests.
|
|
This changes skip_go_tests to invert the sense, and renames it to
allow_go_tests.
|
|
This changes skip_gdbserver_tests to invert the sense, and renames it
to allow_gdbserver_tests.
|
