| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix this:
...
$ empty=$(git hash-object -t tree /dev/null)
$ git diff-index --check $empty gdb/NEWS
gdb/NEWS:1874: space before tab in indent.
+ [--basename | --dirname]
...
and add the file to the clean list in
gdb/contrib/check-whitespace-pre-commit.py.
[ I'm not sure if NEWS has an official style.
There are no settings for NEWS in .gitattributes, so the whitespace attribute
defaults to trailing-space (shorthand for blank-at-eol, blank-at-eof) and
space-before-tab.
We could require either spaces only (tab-in-indent) in gdb/.gitattributes:
...
NEWS whitespace=space-before-tab,tab-in-indent,trailing-space
...
or tab style (indent-with-non-tab):
...
NEWS whitespace=space-before-tab,indent-with-non-tab,trailing-space
...
For tab-in-indent, we get:
...
$ git diff-index --check $empty gdb/NEWS | wc -l
228
...
and for indent-with-non-tab instead:
...
$ git diff-index --check $empty gdb/NEWS | wc -l
40
...
so the more common style seems to be tab style.
But I'm leaving this as is for now. ]
|
|
Add indent-with-non-tab for *.def in gdb*/.gitattributes.
Fix whitespace in the *.def files in gdb*, and add these files to the clean
list in gdb/contrib/check-whitespace-pre-commit.py.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add indent-with-non-tab for *.[ly] in gdb/.gitattributes.
Fix whitespace in the *.[ly] files in gdb, and add these files to the clean
list in gdb/contrib/check-whitespace-pre-commit.py.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix whitespace in the *.c files in gdb, and add these files to the clean list
in gdb/contrib/check-whitespace-pre-commit.py.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix whitespace in the *.h files in gdb, and add these files to the clean list
in gdb/contrib/check-whitespace-pre-commit.py.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch partly rewries dwarf2_get_symbol_read_needs. The goal is
to simplify it and perhaps make it a little more efficient.
With this patch, if an operation simply continues to the next
operation in the expression, then no manipulation of ops_to_visit is
needed. This avoids excess pushes and pops.
Also, visited_ops is changed to be a std::vector<bool> rather than a
map.
Regression tested on x86-64 Fedora 41.
|
|
A user noted that "set environment" does not affect things like
"shell" or "pipe". This makes some sense, because the environment is
per-inferior, and also in the general case it may be affecting a
remote machine -- i.e., the settings may not be locally appropriate.
This patch adds a new set of "local-environment" commands (set, show,
and unset) that affect gdb's own environment.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This changse the various environment-related helper functions to
accept a NULL environment pointer. This special case means that the
function should affect gdb's global environment.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This changes the environment-related helper functions to accept a
pointer argument rather than a reference.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This patch refactors the various environment-related commands into
functions that accept gdb_environ parameter.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
|
|
In a review early in the year:
https://inbox.sourceware.org/gdb-patches/874iz3f4ek.fsf@redhat.com/
Andrew pointed out that a new test I proposed failed with read1.
This test was essentially a copy of gdb.base/environ.exp.
I couldn't reproduce the read1 problem, but this patch rewrites the
one test there that seems like it could possibly fail in this mode.
Now it uses line-by-line mode and checks for a certain environment
variable appearing in the output.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
These includes are reported as unused by clangd.
Change-Id: Ib5c655d9c96e7a612e223bd87d124f90112acc5a
|
|
This include is reported as unused by clangd.
Change-Id: I4fe6048d072d445a2133ac17887fe37ccc5e2d90
|
|
I forgot to update the previous patch based on a review comment before
pushing.
Change-Id: Ib357d105ba67725bfa4772f95d0b658456173be6
|
|
Commit f14bbacae00d ("gdb/guile: remove support for Guile < 2.2")
removed some code supporting Guile 2.0. This patch removes more bits
related to Guile 2.0, and adds a NEWS entry.
* Remove Guile 2.0 mention from the doc.
* Remove HAVE_GUILE_MANUAL_FINALIZATION, assume it is always true.
* Remove guile-2.0 from the versions automatically tried by configure.
* Remove check for scm_new_smob (HAVE_SCM_NEW_SMOB), assume it is
always true.
* Remove hack to fill ac_cv_guild_program_name when the .pc file
wouldn't specify it.
Tested by rebuilding against guile-3.0 and guile-2.2.
Change-Id: I2e89bcd4a4429262f4c3a1c74b275768e60f0cb0
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Add gdbsupport and gdbserver as whitespace-clean in
gdb/contrib/check-whitespace-pre-commit.py.
Likewise for *.ac and *.m4.
Also drop the ignore of configure, that's already taken care of in
.gitattributes.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Simplify regexps in test-case gdb.multi/remote-with-running-inferior.exp using
string_to_regexp and {}.
While we're at it, also break an overly long line.
Tested on x86_64-linux.
|
|
Fix two typos in test-case gdb.multi/remote-with-running-inferior.exp.
|
|
Occasionally, with test-case gdb.multi/remote-with-running-inferior.exp I run
into:
...
(gdb) continue^M
Continuing.^M
^M
Thread 1.1 "remote-with-run" hit Breakpoint 1.1, main () at \
remote-with-running-inferior.c:31^M
31 for (int i = 0; i < 30; ++i)^M
(gdb) PASS: $exp: target_non_stop=auto: non_stop=off: \
continue to breakpoint: continue to breakpoint in breakpt
bt 1^M
(gdb) FAIL: $exp: target_non_stop=auto: non_stop=off: \
check inferior 1 is in breakpt
...
The problem is a race between:
- inferior 1 reaching main, and
- gdb setting a breakpoint on main.
If the breakpoint on main is set before inferior 1 reaches main, the
breakpoint triggers for inferior 1, which the test-case doesn't expect.
Fix this by setting the breakpoint on main only for inferior 2.
Tested on x86_64-linux.
PR testsuite/33621
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33621
|
|
This reverts commit b8524f61e398072f83938fb805f377f22198f9a9.
It was pushed by mistake with an unrelated patch.
|
|
For record full to work on multi-threaded inferiors, we must know to
which thread any given recorded instruction belongs to. This commit adds
this as a new entry for each instruction when an inferior is
multi-threaded. This way, when replaying the instruction, the subsystem
is able to change inferior thread as needed, and avoid SIGILLs when
changing stuff
Ideally, we would only add the PTID entry when we actually need to
switch threads, but that is left as a future improvement.
WIP: replaying doesn't automatically change threads yet, but there was
an attempt
|
|
I found that gettext strings from gdb/cli are not added to gdb.pot.
Fix this by explicitly listing the gdb subdirs in the po/$(PACKAGE).pot rule
in gdb/Makefile.in.
Tested by doing:
...
$ cd build/gdb
$ make po/gdb.pot
...
$ grep -c cli/ po/gdb.pot
345
...
|
|
In commit 4a40fe05bf0 ("[gdb/build] Handle gdbsupport and gdbserver in
gdb.pot"), in order to handle '*.cc' files I did:
...
- -name '*.[hc]' -print
+ -name '*.[hc]' -o -name '*.cc' -print
...
but failed to understand that this no longer printed the '*.[hc]' names.
Fix this by adding a '-print' for '*.[hc]'.
Tested by doing:
...
$ cd build/gdb
$ make po/gdb.pot
...
$ grep -c symtab.c po/gdb.pot
102
...
|
|
In a review to a different patch of mine, Simon asked for this change.
The idea here is that there's no need to pass null as the "field of
this" parameter, as lookup_language_this checks the language anyway.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The pre-commit check check-whitespace checks diffs.
Consequently, we detect something like this:
...
$ echo >> gdb/testsuite/lib/gdb.exp
$ git commit -a -m trailing-empty-line
...
check-whitespace.........................................................Failed
- hook id: check-whitespace
- duration: 0.01s
- exit code: 2
gdb/testsuite/lib/gdb.exp:11717: new blank line at EOF.
...
But say we work around the failing check using --no-verify, then we no longer
detect it after the commit has succeeded:
...
$ git commit -a -m trailing-empty-line --no-verify
[detached HEAD e6302105522] trailing-empty-line
1 file changed, 1 insertion(+)
$ pre-commit run --all-files check-whitespace
check-whitespace.........................................................Passed
- hook id: check-whitespace
- duration: 0.3s
...
Fix this in check-whitespace-pre-commit.sh by distinguishing between clean and
other files. Doing so is easier to do in a more advanced scripting language,
so rewrite into python.
Since a recent commit, gdb/testsuite is clean, so I'm using that as
simple classifier for now.
For the other files we do what we did before, and check just the staging area:
...
$ git --no-pager diff --staged --check "${other[@]}"
...
But for clean files, we check the entire file, including staged changes:
...
$ empty=$(git hash-object -t tree /dev/null)
$ git diff-index --cached --check $empty "${clean[@]}"
...
Consequently, we do see:
...
$ git commit -a -m trailing-empty-line --no-verify
[detached HEAD e6302105522] trailing-empty-line
1 file changed, 1 insertion(+)
$ pre-commit run --all-files check-whitespace
check-whitespace.........................................................Failed
- hook id: check-whitespace
- duration: 0.64s
- exit code: 2
gdb/testsuite/lib/gdb.exp:11717: new blank line at EOF.
...
PR build/33616
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616
|
|
I noticed that when a command line 'list foo.c:10' displays multiple
files, the symbol would always be shown as "???", e.g.:
file: "/tmp/foo.c", line number: 10, symbol: "???"
this is because, when the symtab_and_line is created for the
'foo.c:10', the pc and symbol are never filled in.
In this commit, I propose that, when we decide that the above header
line needs to be printed, we should attempt to lookup a symbol for the
relevant line, and if one is found, we can use that.
The symbol lookup is done by first calling find_pc_for_line, and then
using find_symbol_for_pc to find a suitable symbol.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The gdb.rocm/break-kernel-no-debug-info.exp builds a testcase without
debug info, and loads the binary in GDB with:
gdb_test "file $::binfile" ".*No debugging symbols.*" "load file"
On some configurations (SLES with glibc-devel installed), the compiler
links /usr/lib64/crit1.o (which contains some debug information) into
the final binary. As a result, the binary contains "some" debug
information, which makes the above pattern fail. The testcase is still
valid as we only really need the GPU code object (embedded in the main
binary) to not contain debug information, so this patch proposes to
relax this first step by using "gdb_load" instead.
Tested on x86_64-linux + AMDGPU gfx1031.
Change-Id: Id903f62e170af69c001b39f4681602a54e2fdaf1
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit:
commit c7a45b98a61451f05ff654c4fb72a9c9cb2fba36
Date: Thu Jun 12 15:37:50 2025 +0000
gdb, linespec: avoid multiple locations with same PC
broke GDB's ability to list multiple source files using a 'list'
command. In GDB 16 and earlier something like 'list foo.c:10' could
print multiple results if there were multiple 'foo.c' files compiled
into the executable.
The above commit added a filter to add_sal_to_sals (linespec.c) such
that multiple sals in the same program space, but with the same pc
value, could not be added, only the first sal would actually be
recorded. The problem with this is that add_sal_to_sals is used from
decode_digits_list_mode (also linespec.c) where the pc value is forced
to zero. This force to zero makes sense I think as there might not be
any compiled code for the requested line (this is for 'list' after
all), so there might not be a valid pc to use.
I'm not a fan of using '0' as a special pc value, there are embedded
targets where 0 is a valid pc value, but given we're already using 0
here, I propose to just roll with it.
So, my proposal is that, if the pc is 0, add_sal_to_sals should always
add the sal. This fixes the decode_digits_list_mode, but should keep
the fix that c7a45b98a614 introduced.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33647
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
|
|
On armv7hl-suse-linux-gnu, I run into:
...
(gdb) p/f val.oct
$26 = -5.9822653797615723e-120
(gdb) FAIL: gdb.base/long_long.exp: p/f val.oct
...
There's some complicated logic here in the test-case:
...
if { $sizeof_double == 8 || $sizeof_long_double == 8 } {
# ARM FPA floating point numbers are not strictly little endian or big
# endian, but a hybrid. They are in little endian format with the two
# words swapped in big endian format.
# EABI targets default to natural-endian VFP format.
if { ([istarget "arm*-*-*"]) \
&& !([istarget "*-*-*eabi*"] || \
[istarget "*-*-mingw32ce*"] || \
[istarget "*-*-openbsd*"]) } then {
# assume the long long represents a floating point double in ARM format
gdb_test "p/f val.oct" "2.1386676354387559e\\+265"
} else {
# assume the long long represents a floating point double in little
# endian format
gdb_test "p/f val.oct" "-5.9822653797615723e-120"
}
} else {
gdb_test "p/f val.oct" "-2.42716126e-15"
}
...
which makes the test-case expect the ARM FPA variant.
I think trying to pin down the exact circumstances under which we have ARM FPA
is unnecessary, so I could live with:
...
set re_val_oct_f [string_to_regexp "-5.9822653797615723e-120"]
if { [istarget "arm*-*-*"] } {
set re_val_oct_f_arm_fpa [string_to_regexp "2.1386676354387559e+265"]
re_val_oct_f "$re_val_oct_f|$re_val_oct_f_arm_fpa"
}
....
But instead, I propose to just drop the arm-specific part.
I doubt whether an ARM VPA setup is still part of any test matrix. And if it
is, then I expect other tests to fail as well for the same reason. The ARM
FPA logic is used only once in the test-case, but -5.9822653797615723e-120 is
used more frequently.
Indeed, I wonder the same about setups where -2.42716126e-15 is expected.
On such a setup, won't this fail as well:
...
gdb_test "x/2gf g" "3.5127005640885037e-303.*-5.9822653797615723e-120"
...
?
Unfortunately I'm not sure what setup to use to trigger the -2.42716126e-15
case.
Fix this as good as possible by choosing once between -5.9822653797615723e-120
and -2.42716126e-15, assigning it to re_val_oct_f, and using it everywhere
where those constants are used.
Tested on x86_64-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
PR testsuite/33669
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33669
|
|
A small white space fix in print_gdb_hints. There should be no user
visible changes after this commit.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
I noticed some code in print_gdb_hints that is unused. I rolled a
patch, but while I was doing that commit:
commit 06e470d8fc0ae0e83fe0977fdf8c011998980891
Date: Sat Nov 29 15:48:55 2025 +0100
gdb: handle unlimited screen width case in print_gdb_hints
was merged that deleted some of the code I'd spotted. All that's left
is a 'return' that can be removed, there's nothing after the 'if'
block, the function just returns.
There should be no user visible changes after this commit.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
If an Ada modular type is the same size as gdb's own ULONGEST, ptype
will show "mod 0". This happens because ada_modulus does:
return (ULONGEST) high.const_val () + 1;
This patch cleans this up, replacing ada_modulus with a function to
return the upper bound (if available), and then fixing the various
callers. The type-printing caller still does the "+1", but now this
is done with a gdb_mpz.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33690
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
... to make the current_inferior reference bubble up one level. Since
find_target_at would become a trivial wrapper around
inferior::target_at, remove it. I think it's clearer anyway to see
explicitly that the "subject" of the method call is the inferior.
Change-Id: I73ec44d37e7afea6e85b1689af65e32ae8e5a695
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This changes ada_is_modular_type to return bool.
|
|
This avoids a crash when this function is called while screen width is
unlimited. In such a case (unconditionally occurring in insight), WIDTH
is returned as a negative signed integer, so it has to be compared to
another signed integer, not a size_t.
Also remove an unused WIDTH-sized variable that may fail in the above
case.
|
|
I recently added two requires in test-case gdb.python/py-missing-objfile.exp:
...
# The following tests assume that the build-ids of binfile and libfile can be
# found in the core file.
require {expect_build_id_in_core_file $binfile}
require {expect_build_id_in_core_file $libfile}
...
However, at the point where the check is done, the files are no longer
available at that location, which makes the require fail.
First, make the problem visible, by making proc expect_build_id_in_core_file
throw an error if the filename argument specifies a non-existing file.
Then, fix test-case gdb.python/py-missing-objfile.exp by moving the calls to
expect_build_id_in_core_file to a point where the files exist.
Tested on x86_64-linux.
|
|
The comment says that it returns 0 if the target supports SME and 1 if
it doesn't, but it actually does the opposite. The code does the right
thing, so fix the comment.
|
|
Added record-full support for these extensions.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
I noticed some incorrect indentation in rust-lang.c. This fixes it.
|
|
I propose to remove the code in guile/scm-ports.c supporting Guile <
2.2. The rationale is:
- The code within USING_GUILE_BEFORE_2_2 amounts to about half of the
file, it makes it much more complicated than it would be otherwise.
I'm trying to investigate PR 29825 [1] and this is getting in the
way.
- Guile 2.2, which would now be the baseline for what we require, is
now 8 years old. Guile 2.2 is legacy (the current stable branch is
3.0), but it is still actively packaged [2][3].
- The Guile support code doesn't receive as much contribution, testing
and love as the Python support code, for instance. We don't have
cycles to spare to support an obsolete version of Guile.
This patch removes the USING_GUILE_BEFORE_2_2 define and all the
portions of code within `#if USING_GUILE_BEFORE_2_2`.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29825
[2] https://packages.debian.org/sid/guile-2.2-dev
[3] https://archlinux.org/packages/extra/x86_64/guile2.2/
Change-Id: I926e79cde9835567eb3b7e3d22db402c841b79d7
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
This bug points out that a template parameter that is a constant is
not printed by 'ptype' -- in fact, only type parameters are displayed.
However, there's no real reason for this, and any template parameter
that the DWARF reader can turn into a symbol should be printable.
Note that some parameters are still missing from the DWARF; see the
kfails in the test for details.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33670
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
variable
With test-case gdb.base/until-trailing-insns.exp I run into:
...
ERROR: tcl error code TCL READ VARNAME
ERROR: can't read "_line_unit_advertised_version": no such variable
while executing
"if {$_line_unit_advertised_version == "default"} {
set _line_unit_advertised_version $_line_unit_version
}"
...
Fix this by using the correct variable name in two places in Dwarf::lines:
use _line_unit_advertised_version instead of _line_advertised_unit_version.
Tested on x86_64-linux.
|
|
On openSUSE Leap 15.6 x86_64, with gcc 7 and test-case
gdb.base/condbreak-multi-context.exp I run into:
...
(gdb) print aaa^M
$3 = <optimized out>^M
(gdb) FAIL: $exp: start_before=true: scenario_1: print aaa
...
This is a regression since commit 86ac8c54623 ("Convert
lookup_symbol_in_objfile").
Likewise in test-cases gdb.cp/m-static.exp and gdb.cp/namespace.exp.
The failure is specific to using Dwarf v4:
- using target board unix/gdb:debug_flags=-gdwarf-5 fixes it
- using target board unix/gdb:debug_flags=-gdwarf-4 on Tumbleweed (with gcc 15
and Dwarf v5 default) triggers it
The variable we're trying to print, A::aaa is a static const int member:
...
class A : public Base
{
public:
static const int aaa = 10;
...
};
...
With Dwarf v5, we have this DIE:
...
<2><356>: Abbrev Number: 2 (DW_TAG_variable)
<357> DW_AT_name : aaa
<35c> DW_AT_linkage_name: _ZN1A3aaaE
<364> DW_AT_external : 1
<364> DW_AT_accessibility: 1 (public)
<364> DW_AT_declaration : 1
<364> DW_AT_const_value : 10
...
and the cooked index contains these corresponding entries:
...
[45] ((cooked_index_entry *) 0x7facf0004730)
name: _ZN1A3aaaE
canonical: _ZN1A3aaaE
qualified: _ZN1A3aaaE
DWARF tag: DW_TAG_variable
flags: 0x4 [IS_LINKAGE]
DIE offset: 0x356
parent: ((cooked_index_entry *) 0)
[52] ((cooked_index_entry *) 0x7facf0004700)
name: aaa
canonical: aaa
qualified: A::aaa
DWARF tag: DW_TAG_variable
flags: 0x0 []
DIE offset: 0x356
parent: ((cooked_index_entry *) 0x7facf00046d0) [A]
...
With Dwarf v4, we have instead the following DIE:
...
<2><350>: Abbrev Number: 3 (DW_TAG_member)
<351> DW_AT_name : aaa
<35b> DW_AT_external : 1
<35b> DW_AT_accessibility: 1 (public)
<35c> DW_AT_declaration : 1
<35c> DW_AT_const_value : 4 byte block: a 0 0 0
...
and there are no corresponding entries.
Fix this by adding an entry:
...
[47] ((cooked_index_entry *) 0x7f5a24004660)
name: aaa
canonical: aaa
qualified: A::aaa
DWARF tag: DW_TAG_member
flags: 0x0 []
DIE offset: 0x350
parent: ((cooked_index_entry *) 0x7f5a24004630) [A]
...
Add a regression test in the form of a dwarf assembly test-case printing the
value of variable A::aaa.
In the test-case, for A::aaa, DW_FORM_flag is used to encode
DW_AT_declaration. In v1 of this patch that mattered (because of using
has_hardcoded_declaration in abbrev_table::read), but that's no longer the
case. Nevertheless, also add an A::bbb using FORM_flag_present for
DW_AT_declaration (and while we're at it, DW_AT_external as well).
Also add two variants, for which <optimized out> is printed:
- A::ccc: a variant with DW_AT_location instead of DW_AT_const_value, and
- A::ddd: a variant without external.
This behavior is not part of the regression. I've reproduced it using a
system gdb based on 14.2. It's also not specific to using the cooked index,
it reproduces with -readnow as well.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/33415
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33415
|
|
The Free Pascal Compiler fpc supports generating different versions of DWARF:
...
$ fpc -h
Free Pascal Compiler version 3.2.2 [2025/09/10] for x86_64
...
-gw Generate DWARFv2 debug information (same as -gw2)
-gw2 Generate DWARFv2 debug information
-gw3 Generate DWARFv3 debug information
-gw4 Generate DWARFv4 debug information (experimental)
...
The v4 support is experimental, and indeed the line number information is
broken (missing maximum_operations_per_instruction field in the .debug_line
header), so setting a breakpoint on a line number is not possible:
...
$ fpc -gw4 hello.pas
...
$ gdb -q hello
Reading symbols from hello...
(gdb) b hello.pas:8
No compiled code for line 8 in file "hello.pas".
Make breakpoint pending on future shared library load? (y or [n])
...
The brokenness is detected by llvm-dwarfdump (second warning):
...
$ llvm-dwarfdump -debug-line hello
hello: file format elf64-x86-64
.debug_line contents:
debug_line[0x00000000]
warning: parsing line table prologue at offset 0x0 found opcode base of 0. \
Assuming no standard opcodes
warning: unknown data in line table prologue at offset 0x0: parsing ended (at \
offset 0x00000017) before reaching the prologue end at offset 0x2a
...
Likewise, detect the situation the second warning describes in
dwarf_decode_line_header, getting us instead:
...
(gdb) b hello.pas:8
❌malformed line number program header, advertised length does not match \
actual length
(gdb)
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Fix the following typos:
...
gdb/dwarf2/cooked-index-shard.c:296: re-use ==> reuse
gdb/dwarf2/read-gdb-index.c:629: re-use ==> reuse
gdb/dwarf2/read.c:2399: re-using ==> reusing
gdb/dwarf2/read.c:11692: endianity ==> endianness
gdb/dwarf2/read.c:11694: endianity ==> endianness
gdb/dwarf2/read.c:11696: endianity ==> endianness
gdb/dwarf2/read.c:11709: endianity ==> endianness
...
Add aranges to the ignore list.
Also replace readin by "read_in".
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This is the result of:
...
$ git rm -f $(find gdb* -name "*.ac")
$ git rm -f $(find gdb* -name "*.m4")
$ git commit -a -m tmp
$ git revert HEAD
$ git rebase --whitespace=fix HEAD^
$ git reset --soft HEAD^
$ git commit --amend
...
and running autoreconf -f in directories gdb, gdb/testsuite, gdbsupport and
gdbserver.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Since commit 52ca3d3fe61 ("toplevel: unify the GCC and GDB/binutils .editorconfig
files"), .editorconfig has settings for .ac and .m4 files:
...
[*.{ac,m4}]
indent_style = tab
indent_size = 2
trim_trailing_whitespace = true
...
There are no setting for those files in .gitattributes, so the whitespace
attribute defaults to trailing-space (shorthand for blank-at-eol,
blank-at-eof) and space-before-tab.
Since according to .editorconfig the indentation style is tab, add
indent-with-non-tab as well.
Since aclocal.m4 is generated, unset the whitespace attribute. Likewise for
configure.
Probably, this eventually needs to be added to root level .gitattributes, but
for now try this in gdb*/.gitattributes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
When trying to cross-compile GDB to sparc-buildroot-linux-uclibc, I get:
CXX ser-unix.o
In file included from /data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/termios.h:39,
from /home/smarchi/src/binutils-gdb/gdb/ser-unix.c:51:
/data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/bits/termios.h:26:22: error: conflicting declaration ‘typedef unsigned int tcflag_t’
26 | typedef unsigned int tcflag_t;
| ^~~~~~~~
In file included from /home/smarchi/src/binutils-gdb/gdb/ser-unix.c:46:
/data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:13:25: note: previous declaration as ‘typedef long unsigned int tcflag_t’
13 | typedef unsigned long tcflag_t;
| ^~~~~~~~
uClibc and the kernel don't agree on the definition of tcflag_t for this
architecture. Here' uClibc [1]:
typedef unsigned int tcflag_t;
And here's the kernel [2]:
#if defined(__sparc__) && defined(__arch64__)
typedef unsigned int tcflag_t;
#else
typedef unsigned long tcflag_t; <--- that branch is take
#endif
glibc [3] has the same definition as uClibc, so we would get the same
problem.
I propose to work around this the same way as we handle differences in
the termios structure, by renaming the version from the kernel.
I opened a bug on the glibc bugzilla [4] to ask if this is something
that would need to be fixed on the libc side, but in the mean time we
need to work around it.
[1] https://github.com/kraj/uClibc/blob/ca1c74d67dd115d059a875150e10b8560a9c35a8/libc/sysdeps/linux/sparc/bits/termios.h#L26
[2] https://github.com/torvalds/linux/blob/e7c375b181600caf135cfd03eadbc45eb530f2cb/arch/sparc/include/uapi/asm/termbits.h#L7-L11
[3] https://gitlab.com/gnutools/glibc/-/blob/efc8642051e6c4fe5165e8986c1338ba2c180de6/bits/termios.h#L104
[4] https://sourceware.org/bugzilla/show_bug.cgi?id=33643
Change-Id: I71c6e0df5ac8e2ff3db3233a2220faaf70c3df6d
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The .size calculation for bar's function incorrectly uses the label func
instead of bar. Fix it.
Signed-off-by: Yu-Cheng Liang <yclwlcy@gmail.com>
|
|
This rewrites the Objective-C @selector implementation in c-exp.y,
following a couple general comments in the patch supplied for
bug 20503.
I suspect something else changed in the Objective-C runtime, though,
as most of the examples in that bug still do not work, even though
this series (I believe) addresses all the same points.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20503
|
