| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Re-format all Python files using black [1] version 21.4b0.
This specific version (currently the latest) can be installed using:
$ pip3 install 'black == 21.4b0'
All you need to do to re-format files is run `black <file/directory>`,
and black will re-format any Python file it finds in there. It runs
quite fast, so the simplest is probably to do:
$ black gdb/
from the top-level.
Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
|
|
Bug 27773 shows that passing a filename in a non-existent directory to
the "dump binary" command leads to a gdb crash. This is because the
gdb_fopen_cloexec in dump_binary_file fails (returns nullptr) and the
return value is not checked. Fix that by erroring out if
gdb_fopen_cloexec fails.
gdb/ChangeLog:
PR gdb/27773
* cli/cli-dump.c (dump_binary_file): Check result of
gdb_fopen_cloexec.
gdb/testsuite/ChangeLog:
PR gdb/27773
* gdb.base/dump.exp: Test dump to non-existent dir.
Change-Id: Iea89a3bf9e6b9dcc31142faa5ae17bc855759328
|
|
The test checks for a particular ARCH level, but it needs to check for
ARCH levels from a minimum and upwards.
gdb/testsuite/ChangeLog:
2021-04-26 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-dbreg-contents.c (set_watchpoint): Fix arch level
comparison.
|
|
On sparc build failed as:
```
gdb/sparc-linux-nat.c: In member function
'virtual void sparc_linux_nat_target::fetch_registers(regcache*, int)':
gdb/sparc-linux-nat.c:36:37:
error: cannot convert 'regcache*' to 'process_stratum_target*'
36 | { sparc_fetch_inferior_registers (regcache, regnum); }
| ^~~~~~~~
| |
| regcache*
```
The fix adopts gdb/sparc-nat.h API change in d1e93af64a6
("gdb: set current thread in sparc_{fetch,collect}_inferior_registers").
gdb/ChangeLog:
* sparc-linux-nat.c (sparc_linux_nat_target): fix sparc build
by passing `process_stratum_target*` parameter.
|
|
This commit adds a flag to the ptype command in order to print the
offsets and sizes of struct members using the hexadecimal notation. The
'x' flag ensures use of the hexadecimal notation while the 'd' flag
ensures use of the decimal notation. The default is to use decimal
notation.
Before this patch, gdb only uses decimal notation, as pointed out in PR
gdb/22640.
Here is an example of this new behavior with hex output turned on:
(gdb) ptype /ox struct type_print_options
/* offset | size */ type = struct type_print_options {
/* 0x0000: 0x0 | 0x0004 */ unsigned int raw : 1;
/* 0x0000: 0x1 | 0x0004 */ unsigned int print_methods : 1;
/* 0x0000: 0x2 | 0x0004 */ unsigned int print_typedefs : 1;
/* 0x0000: 0x3 | 0x0004 */ unsigned int print_offsets : 1;
/* 0x0000: 0x4 | 0x0004 */ unsigned int print_in_hex : 1;
/* XXX 3-bit hole */
/* XXX 3-byte hole */
/* 0x0004 | 0x0004 */ int print_nested_type_limit;
/* 0x0008 | 0x0008 */ typedef_hash_table *local_typedefs;
/* 0x0010 | 0x0008 */ typedef_hash_table *global_typedefs;
/* 0x0018 | 0x0008 */ ext_lang_type_printers *global_printers;
/* total size (bytes): 32 */
}
This patch also adds the 'set print type hex' and 'show print type hex'
commands in order to set and inspect the default behavior regarding the
use of decimal or hexadecimal notation when printing struct sizes and
offsets.
Tested using on x86_64.
gdb/ChangeLog:
PR gdb/22640
* typeprint.h (struct type_print_options): Add print_in_hex
flag.
(struct print_offset_data): Add print_in_hex flag, add a
constructor accepting a type_print_options* argument.
* typeprint.c (type_print_raw_options, default_ptype_flags): Set
default value for print_in_hex.
(print_offset_data::indentation): Allow more horizontal space.
(print_offset_data::print_offset_data): Add ctor.
(print_offset_data::maybe_print_hole, print_offset_data::update):
Handle the print_in_hex flag.
(whatis_exp): Handle 'x' and 'd' flags.
(print_offsets_and_sizes_in_hex): Declare.
(set_print_offsets_and_sizes_in_hex): Create.
(show_print_offsets_and_sizes_in_hex): Create.
(_initialize_typeprint): Update help message for the ptype
command, register the 'set print type hex' and 'show print type
hex' commands.
* c-typeprint.c (c_print_type, c_type_print_base_struct_union)
(c_type_print_base): Construct the print_offset_data
object using the type_print_optons parameter.
* rust-lang.c (rust_language::print_type): Construct the
print_offset_data object using the type_print_optons parameter.
* NEWS: Mention the new flags of the ptype command.
gdb/doc/ChangeLog:
PR gdb/22640
* gdb.texinfo (Symbols): Describe the 'x' and 'd' flags of the
ptype command, describe 'set print type hex' and 'show print
type hex' commands. Update 'ptype/o' examples.
gdb/testsuite/ChangeLog:
PR gdb/22640
* gdb.base/ptype-offsets.exp: Add tests to verify the behavior
of 'ptype/ox' and 'ptype/od'. Check that 'set print type hex'
changes the default behavior of 'ptype/o'. Update to take into
account new horizontal layout.
* gdb.rust/simple.exp: Update ptype test to check new horizontal
layout.
* gdb.rust/union.exp: Same.
|
|
Move the declaration of struct type_print_raw_options before struct
print_offset_data to ease upcoming changes. This is a helper commit
intended to make it easier to build a print_offset_data object from
configurations given by a type_print_raw_options.
gdb/ChangeLog:
* typeprint.h (struct type_print_options): Move before
print_offset_data.
|
|
gdb/ChangeLog:
GDB 10.2 released.
|
|
Give a name to each observer, this will help produce more meaningful
debug message.
gdbsupport/ChangeLog:
* observable.h (class observable) <struct observer> <observer>:
Add name parameter.
<name>: New field.
<attach>: Add name parameter, update all callers.
Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0
|
|
gdb/ChangeLog:
* observable.c (observer_debug): Change to bool.
gdbsupport/ChangeLog:
* observable.h (observer_debug): Change to bool.
Change-Id: I58634235a20740a66eacb1c83bae3cf3304ae1fd
|
|
While working on some changes to 'info sources' I ran into a situation
where I was seeing the same source files reported twice in the output
of the 'info sources' command when using either .gdb_index or the
.debug_name index.
I traced the problem back to some caching in
dwarf2_base_index_functions::map_symbol_filenames; when called GDB
caches the set of filenames, but, filesnames are not removed as the
index entries are expanded into full symtabs. As a result we can end
up seeing filenames reported both from a full symtab _and_ from
a (stale) previously cached index entry.
Now, obviously, when seeing a problem like this the "correct" fix is
to remove the stale entries from the cache, however, I ran a few
experiments to see why this wasn't really hitting us anywhere, and, as
far as I can tell, ::map_symbol_filenames is only called from three
places:
1. The mi command -file-list-exec-source-files,
2. The 'info sources' command, and
3. Filename completion
However, the result of this "bug" is that we will see duplicate
filenames, and readline's completion mechanism already removes
duplicates, so for case #3 we will never see any problems.
Cases #1 and #2 are basically the same, and in each case, to see a
problem we need to ensure we craft the test in a particular way, start
up ensuring we have some unexpected symtabs, then run one of the
commands to populate the cache, then expand one of the symtabs, and
list the sources again. At this point you'll see duplicate entries in
the results. Hardly surprising we haven't randomly hit this situation
in testing.
So, considering that use cases #1 and #2 are certainly not "high
performance" code (i.e. I don't think these justify the need for
caching) this leaves use case #3. Does this use justify the need for
caching? Well the psymbol_functions::map_symbol_filenames function
doesn't seem to do any extra caching, and within
dwarf2_base_index_functions::map_symbol_filenames, the only expensive
bit appears to be the call to dw2_get_file_names, and this already
does its own caching via this_cu->v.quick->file_names.
The upshot of all this analysis was that I'm not convinced the need
for the additional caching is justified, and so, I propose that to fix
the bug in GDB, I just remove the extra caching (for now).
If we later find that the caching _was_ useful, then we can
reintroduce it, but add it back such that it doesn't reintroduce this
bug.
As I was changing dwarf2_base_index_functions::map_symbol_filenames I
replaced the use of htab_up with std::unordered_set.
Tested using target_boards cc-with-debug-names and dwarf4-gdb-index.
gdb/ChangeLog:
* dwarf2/read.c: Add 'unordered_set' include.
(dwarf2_base_index_functions::map_symbol_filenames): Replace
'visited' hash table with 'qfn_cache' unordered_set. Remove use
of per_Bfd->filenames_cache cache, and use function local
filenames_cache instead. Reindent.
* dwarf2/read.h (struct dwarf2_per_bfd) <filenames_cache>: Delete.
gdb/testsuite/ChangeLog:
* gdb.base/info_sources.exp: Add new tests.
|
|
Use a function_view instead of function pointer + data. Actually,
nothing uses the data anyway, but that makes iterate_over_bp_locations
more like iterate_over_breakpoints.
gdb/ChangeLog:
* breakpoint.c (iterate_over_bp_locations): Change callback to
function view, remove data parameter.
* breakpoint.h (iterate_over_bp_locations): Likewise.
* record-full.c (record_full_sync_record_breakpoints): Remove
data parameter.
Change-Id: I66cdc94a505f67bc640bcc66865fb535ee939a57
|
|
I noticed that when using ptype/o, the "<no data fields>" text that
may be emitted is indented incorrectly. This patch fixes the bug and
adds a new test case.
I also removed a stray backslash from ptype-offsets.exp that I noticed
while writing the test. This seemed too trivial to warrant a separate
patch.
gdb/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* c-typeprint.c (c_type_print_base_struct_union): Use
print_spaces_filtered_with_print_options.
gdb/testsuite/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* gdb.base/ptype-offsets.cc (struct empty_member): New.
(main): Use empty_member.
* gdb.base/ptype-offsets.exp: Add new test.
|
|
We don't want to execute this test if Python support is not compiled in
GDB, add the necessary check.
gdb/testsuite/ChangeLog:
* gdb.python/flexible-array-member.exp: Add check for Python
support.
Change-Id: I853b937d2a193a0bb216566bef1a35354264b1c5
|
|
As reported in bug 27757, we get an internal error when doing:
$ cat test.c
struct foo {
int len;
int items[];
};
struct foo *p;
int main() {
return 0;
}
$ gcc test.c -g -O0 -o test
$ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
Reading symbols from ./test...
/home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is because the Python code (typy_range) blindly reads the high
bound of the type of `items` as a constant value. Since it is a
flexible array member, it has no high bound, the property is undefined.
Since commit 8c2e4e0689 ("gdb: add accessors to struct dynamic_prop"),
the getters check that you are not getting a property value of the wrong
kind, so this causes a failed assertion.
Fix it by checking if the property is indeed a constant value before
accessing it as such. Otherwise, use 0. This restores the previous GDB
behavior: because the structure was zero-initialized, this is what was
returned before. But now this behavior is explicit and not accidental.
Add a test, gdb.python/flexible-array-member.exp, that is derived from
gdb.base/flexible-array-member.exp. It tests the same things, but
through the Python API. It also specifically tests getting the range
from the various kinds of flexible array member types (AFAIK it wasn't
possible to do the equivalent through the CLI).
gdb/ChangeLog:
PR gdb/27757
* python/py-type.c (typy_range): Check that bounds are constant
before accessing them as such.
* guile/scm-type.c (gdbscm_type_range): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/27757
* gdb.python/flexible-array-member.c: New test.
* gdb.python/flexible-array-member.exp: New test.
* gdb.guile/scm-type.exp (test_range): Add test for flexible
array member.
* gdb.guile/scm-type.c (struct flex_member): New.
(main): Use it.
Change-Id: Ibef92ee5fd871ecb7c791db2a788f203dff2b841
|
|
Turn continuations-related functions into methods of the inferior
class. This is a refactoring.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* Makefile.in (COMMON_SFILES): Remove continuations.c.
* inferior.c (inferior::add_continuation): New method, adapted
from 'add_inferior_continuation'.
(inferior::do_all_continuations): New method, adapted from
'do_all_inferior_continuations'.
(inferior::~inferior): Clear the list of continuations directly.
* inferior.h (class inferior) <continuations>: Rename into...
<m_continuations>: ...this and make private.
* continuations.c: Remove.
* continuations.h: Remove.
* event-top.c: Don't include "continuations.h".
Update the users below.
* inf-loop.c (inferior_event_handler)
* infcmd.c (attach_command)
(notice_new_inferior): Update.
|
|
Use lambdas and std::list to track inferior continuations. This is a
refactoring.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* inferior.h (class inferior) <continuations>: Change the type
to be an std::list of std::function's.
Update the references and uses below.
* continuations.c (struct continuation): Delete.
(make_continuation): Delete.
(do_my_continuations_1): Delete.
(do_my_continuations): Delete.
(discard_my_continuations_1): Delete.
(discard_my_continuations): Delete.
(add_inferior_continuation): Update.
(do_all_inferior_continuations): Update.
(discard_all_inferior_continuations): Update.
* continuations.h (add_inferior_continuation): Update to take
an std::function as the parameter.
* infcmd.c (struct attach_command_continuation_args): Delete.
(attach_command_continuation): Delete.
(attach_command_continuation_free_args): Delete.
(attach_command): Update.
(notice_new_inferior): Update.
|
|
Inferior continuations are no longer used by the until and finish
command. It is used only by the attach command and the remote target
upon detecting new inferiors. Update the comment accordingly.
Also update another comment about non-existent thread continuations and
remove an unused #include.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* continuations.h: Update the general comment.
* inferior.h (class inferior) <continuations>: Update the comment.
* interps.c: Do not include "continuations.h".
|
|
The 'err' parameter of 'do_all_inferior_continuations' is effectively
unused. There is only one place where the function is called, and
there the argument is a literal 0. So, remove the parameter.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* continuations.h (do_all_inferior_continuations): Remove the 'err'
parameter. Update the references below.
* continuations.c (do_my_continuations_1)
(do_my_continuations)
(do_all_inferior_continuations): Update.
* inf-loop.c (inferior_event_handler): Update.
* infcmd.c (attach_command_continuation): Update.
|
|
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcmd.c (attach_post_wait): Update the function comment.
|
|
The 'arg' parameter of 'attach_post_wait' is unused. Remove it.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcmd.c (attach_post_wait): Remove the unused parameter 'args'.
Update the references below.
(struct attach_command_continuation_args)
(attach_command_continuation)
(attach_command_continuation_free_args)
(attach_command)
(notice_new_inferior): Update to remove the reference to 'args'.
|
|
Occassionally I run into the following assert:
...
(gdb) PASS: gdb.multi/multi-target-continue.exp: inferior 5
Remote debugging from host ::1, port 49990^M
Process multi-target-continue created; pid = 31241^M
src/gdb/remote-notif.c:113: internal-error: \
void remote_async_get_pending_events_handler(gdb_client_data): \
Assertion `target_is_non_stop_p ()' failed.^M
...
The assert checks target_is_non_stop_p, which is related to the current
target.
Fix this by changing the assert such that it checks non-stopness related to
the event it's handling.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-04-22 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR remote/27710
* remote.c (remote_target_is_non_stop_p): New function.
* remote.h (remote_target_is_non_stop_p): Declare.
* remote-notif.c (remote_async_get_pending_events_handler): Fix assert
to check non-stopness using notif_state->remote rather current target.
|
|
I enabled code coverage and ran the gdb test suite, and noticed that
the new Rust parser was missing testing on a few lines that were easy
to cover. This patch mostly adds tests for certain syntax errors; but
this process also uncovered a couple of real bugs: I must have
cut-and-pasted the 'sizeof' parsing code from some other code, because
it is checking for KW_MUT (the old bison parser did not do this), and
the array length check is actually impossible because a negative
number like '-1' is parsed as two tokens.
gdb/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* rust-parse.c (rust_parser::parse_sizeof): Remove KW_MUT code.
(struct typed_val_int) <val>: Now ULONGEST.
(rust_parser::parse_array_type): Remove negative check.
(rust_lex_int_test): Change 'value' to ULONGEST.
gdb/testsuite/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* gdb.rust/modules.exp: Add checks for syntax errors.
* gdb.rust/expr.exp: Add checks for syntax errors.
* gdb.rust/simple.exp: Add checks for syntax errors.
|
|
Currently default_addressable_memory_unit_size always returns 1,
indicating 1 byte is 1 octet. If a target has something other than
this (common) setup then the target should override the
default_addressable_memory_unit_size.
However, the bfd library already knows about each targets octets per
byte, so it seems redundant making targets override this method to
tell GDB something it already knows (through bfd).
In this commit I propose to make default_addressable_memory_unit_size
return a value based on bfd's bits per byte. I checked, and for every
target that GDB currently supports the bits per byte in bfd is 8, so
the current behaviour will not change.
In fact, the only targets in bfd that have bits per byte set to
something other than 8 can be found in cpu-tic4x.c and cpu-tic54x.c, I
don't believe these are supported by GDB right now.
I don't propose to remove the ability to override
default_addressable_memory_unit_size, this allows targets additional
flexibility for how to handle weird combinations of byte sizes.
This change was motivated by an out of tree target I was working on,
but it seemed like it was a good change that others might benefit
from.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* arch-utils.c (default_addressable_memory_unit_size): Return a
value based on bfd's bits per byte.
|
|
I noticed some holes in struct dwarf2_per_cu_data. This patch
rearranges the type slightly, and shrinks the size of some fields.
This reduces it from 136 bytes to 112 bytes (on x86-64).
I also reduced the size of the DWARF "version" fields in a couple of
spots. It seemed needless to use a short to hold a value that ranges
from 2 to 5, and this also helped the goal of shrinking
dwarf2_per_cu_data.
2021-04-21 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_cu_data) <dwarf_version>: Now
unsigned char.
(struct dwarf2_per_cu_data): Rearrange.
* dwarf2/comp-unit.h (struct comp_unit_head) <version>: Now
unsigned char.
(struct comp_unit_head): Rearrange.
* dwarf2/comp-unit.c (read_comp_unit_head): Update.
|
|
gdb/testsuite/ChangeLog:
* gdb.base/valgrind-bt.exp: Add gdb_test "break main".
Update expected string for gdb_test "bt".
* lib/valgrind.exp: Add set remotetimeout 3.
Increase vgdb wait from 1 to 2.
Add max-invoke-ms option to vgdb command line.
|
|
Currently gdb has a configure option:
...
$ ./src/gdb/configure --help
...
--without-included-regex
don't use included regex; this is the default on
systems with version 2 of the GNU C library (use
with caution on other system)
...
The configure option controls config.h macro USE_INCLUDED_REGEX, which is
used in gdb/gdb_regex.h to choose between:
- using regex from libiberty (which is included in the binutils-gdb.git repo,
hence the 'included' in USE_INCLUDED_REGEX), or
- using regex.h.
In the former case, the symbol regcomp is remapped to a symbol xregcomp, which
is then provided by libiberty.
In the latter case, the symbol regcomp is resolved at runtime, usually binding
to libc. However, there is no mechanism in place to enforce this.
PR27681 is an example of where that causes problems. On openSUSE Tumbleweed,
the ncurses package got the --with-pcre2 configure switch enabled, and solved
the resulting dependencies using:
...
$ cat /usr/lib64/libncursesw.so
/* GNU ld script */
-INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl))
+INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl -lpcre2-posix -lpcre2-8))
...
This lead to regcomp being bound to libpcre2-posix instead of libc.
This causes problems in several ways:
- by compiling using regex.h, we've already chosen a specific regex_t
implementation, and the one from pcre2-posix is not the same.
- in gdb_regex.c we use GNU regex function re_search, which pcre2-posix
doesn't provide, so while regcomp binds to pcre2-posix, re_search binds to
libc.
A note on the latter: it's actually a bug to compile a regex using regcomp and
then pass it to re_search. The GNU regex interface requires one to use
re_compile_pattern or re_compile_fastmap. But as long we're using one of the
GNU regex incarnations in gnulib, glibc or libiberty, we get away with this.
The PR could be fixed by adding -lc in a specific position in the link line,
to force regcomp to be bound to glibc. But this solution was considered
in the discussion in the PR as being brittle, and possibly causing problems
elsewhere.
Another solution offered was to restrict regex usage to posix, and no longer
use the GNU regex API. This however could mean having to reproduce some of
that functionality locally, which would mean maintaining the same
functionality in more than one place.
The solution chosen here, is to hardcode --with-included-regex, that is, using
libiberty.
The option of using glibc for regex was introduced because glibc became the
authorative source for GNU regex, so it offered the possibility to link
against a more up-to-date regex version.
In that aspect, this patch is a step back. But we have the option of using a
more up-to-date regex version as a follow-up step: by using the regex from
gnulib.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-04-21 Tom de Vries <tdevries@suse.de>
PR build/27681
* configure.ac: Remove --without-included-regex/--with-included-regex.
* config.in: Regenerate.
* configure: Regenerate.
* gdb_regex.h: Assume USE_INCLUDED_REGEX is defined.
|
|
The 'create_breakpoint' function takes a 'parse_extra' argument that
determines whether the condition, thread, and force-condition
specifiers should be parsed from the extra string or be used from the
function arguments. However, for the case when 'parse_extra' is
false, there is no way to pass the force-condition specifier. This
patch adds it as a new argument.
Also, in the case when parse_extra is false, the current behavior is
as if the condition is being forced. This is a bug. The default
behavior should reject the breakpoint. See below for a demo of this
incorrect behavior. (The MI command '-break-insert' uses the
'create_breakpoint' function with parse_extra=0.)
$ gdb -q --interpreter=mi3 /tmp/simple
=thread-group-added,id="i1"
=cmd-param-changed,param="history save",value="on"
=cmd-param-changed,param="auto-load safe-path",value="/"
~"Reading symbols from /tmp/simple...\n"
(gdb)
-break-insert -c junk -f main
&"warning: failed to validate condition at location 1, disabling:\n "
&"No symbol \"junk\" in current context.\n"
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="1.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
(gdb)
break main if junk
&"break main if junk\n"
&"No symbol \"junk\" in current context.\n"
^error,msg="No symbol \"junk\" in current context."
(gdb)
break main -force-condition if junk
&"break main -force-condition if junk\n"
~"Note: breakpoint 1 also set at pc 0x114e.\n"
&"warning: failed to validate condition at location 1, disabling:\n "
&"No symbol \"junk\" in current context.\n"
~"Breakpoint 2 at 0x114e: file /tmp/simple.c, line 2.\n"
=breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="2.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
^done
(gdb)
After applying this patch, we get the behavior below:
(gdb)
-break-insert -c junk -f main
^error,msg="No symbol \"junk\" in current context."
This restores the behavior that is present in the existing releases.
gdb/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (create_breakpoint): Add a new parameter,
'force_condition'.
* breakpoint.c (create_breakpoint): Use the 'force_condition'
argument when 'parse_extra' is false to check if the condition
is invalid at all of the breakpoint locations.
Update the users below.
(break_command_1)
(dprintf_command)
(trace_command)
(ftrace_command)
(strace_command)
(create_tracepoint_from_upload): Update.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Update.
* python/py-breakpoint.c (bppy_init): Update.
* python/py-finishbreakpoint.c (bpfinishpy_init): Update.
gdb/testsuite/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp: Extend with checks for invalid breakpoint
conditions.
|
|
gdb/testsuite/ChangeLog:
2021-04-21 Simon Marchi <simon.marchi@polymtl.ca>
Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp: Fix the duplicate test names.
|
|
For breakpoint locations that are disabled because of an invalid
condition, CLI displays "N*" in the 'enabled' field, where '*' refers
to the footnote below the table:
(*): Breakpoint condition is invalid at this location.
This is not necessary for MI, where we shall simply print "N" without
the footnote.
Update the document to mention the "N" value for the MI. Also remove
the line about the 'enable' field, because there is no such field for
locations.
gdb/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.c (print_one_breakpoint_location): Display "N" for
disabled-by-condition locations on MI-like output.
(breakpoint_1): Do not display the disabled-by-condition footnote
if the output is MI-like.
gdb/doc/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (GDB/MI Breakpoint Information): Update the
description for the 'enabled' field of breakpoint locations.
|
|
Fix the script name and year range in update-netbsd.sh.
gdb/ChangeLog
2021-04-21 Frederic Cambus <fred@statdns.com>
* syscalls/update-netbsd.sh: Fix script name display in usage, and
update year range in generated copyright notices.
|
|
This fixes a problem with GDB's address space qualifier parsing. GDB uses
'@' as a way to express an address space in expression evaluation. This can
currently lead to a crash for "Add support for the __flash qualifier on AVR"
(487d975399dfcb2bb2f0998a7d12bd62acdd9fa1), the only user I am aware of.
Program:
~~~
const __flash char data_in_flash = 0xab;
int
main (void)
{
const __flash char *pointer_to_flash = &data_in_flash;
}
~~~
Before:
~~~
(gdb) p data_in_flash
$1 = -85 '\253'
(gdb) p *(const char * @flash) pointer_to_flash
$2 = -85 '\253'
(gdb) p *(@flash const char *) pointer_to_flash
type-stack.c:201: internal-error: type* type_stack::follow_types(type*): unrecognized tp_ value in follow_types
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
~~~
After:
~~~
(gdb) p data_in_flash
$1 = -85 '\253'
(gdb) p *(const char *) pointer_to_flash
$2 = 0 '\000'
(gdb) p *(const char * @flash) pointer_to_flash
$3 = -85 '\253'
(gdb) p *(@flash const char *) pointer_to_flash
$4 = 0 '\000'
(gdb)
~~~
Note that how the binding of this qualifier is interpreted and resolved for an
address/pointer is target specific. Hence only the prepended qualifier works
for AVR, even if it seems syntactically incorrect. I won't change this for
AVR, as I am not familiar with that target.
Bison now also complains about less conflicts:
Before:
YACC c-exp.c
gdb/gdb/c-exp.y: warning: 153 shift/reduce conflicts [-Wconflicts-sr]
gdb/gdb/c-exp.y: warning: 70 reduce/reduce conflicts [-Wconflicts-rr]
After:
YACC c-exp.c
gdb/gdb/c-exp.y: warning: 60 shift/reduce conflicts [-Wconflicts-sr]
gdb/gdb/c-exp.y: warning: 69 reduce/reduce conflicts [-Wconflicts-rr]
gdb/ChangeLog:
2021-04-20 Felix Willgerodt <felix.willgerodt@intel.com>
* c-exp.y (qualifier_seq_noopt): Replace qualifier_seq with
qualifier_seq_noopt.
|
|
The goal of this patch is to allow target dependent address space qualifiers
in the C++ expression parser. This can be useful for memory examination on
targets that actually use different address spaces in hardware without
having to deep-dive into implementation details of the whole solution.
GDB uses the @ symbol to parse address space qualifiers. The only current
user that I am aware of is the __flash support for avr, which was added in
"Add support for the __flash qualifier on AVR"
(487d975399dfcb2bb2f0998a7d12bd62acdd9fa1)
and only works for C.
One use-case of the AVR patch is:
~~~
const __flash char data_in_flash = 0xab;
int
main (void)
{
const __flash char *pointer_to_flash = &data_in_flash;
}
~~~
~~~
(gdb) print pointer_to_flash
$1 = 0x1e8 <data_in_flash> "\253"
(gdb) print/x *pointer_to_flash
$2 = 0xab
(gdb) x/x pointer_to_flash
0x1e8 <data_in_flash>: 0xXXXXXXab
(gdb)
(gdb) p/x *(char* @flash) pointer_to_flash
$3 = 0xab
~~~
I want to enable a similar usage of e.g. @local in C++.
Before this patch (using "set debug parser on"):
~~~
(gdb) p *(int* @local) 0x1234
(...)
Reading a token: Next token is token '@' ()
Shifting token '@' ()
Entering state 46
Reading a token: Next token is token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
A syntax error in expression, near `local) &x'.
~~~
After:
~~~
(gdb) p *(int* @local) 0x1234
(...)
Reading a token: Next token is token '@' ()
Shifting token '@' ()
Entering state 46
Reading a token: Next token is token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
Shifting token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
Entering state 121
Reducing stack by rule 278 (line 1773):
$1 = token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
-> $$ = nterm name ()
Stack now 0 49 52 76 222 337 46
Entering state 167
Reducing stack by rule 131 (line 1225):
$1 = token '@' ()
$2 = nterm name ()
Unknown address space specifier: "local"
~~~
The "Unknown address space qualifier" is the right behaviour, as I ran this
on a target that doesn't have multiple address spaces and therefore obviously
no support for such qualifiers.
gdb/ChangeLog:
2021-04-20 Felix Willgerodt <felix.willgerodt@intel.com>
* c-exp.y (single_qualifier): Handle UNKNOWN_CPP_NAME.
gdb/testsuite/ChangeLog:
2021-04-20 Felix Willgerodt <felix.willgerodt@intel.com>
* gdb.base/address_space_qualifier.exp: New file.
|
|
In GDB we should be using compiled_regex instead of std::regex.
Replace one use in producer.c.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* producer.c: Replace 'regex' include with 'gdb_regex.h'.
(producer_is_icc): Replace use of std::regex with gdb's
compiled_regex.
|
|
PR gdb/27742 points out that my recent change to
print_variable_and_value caused a regression in inline-locals.exp. I
can't reproduce this, but I came up with this patch based on the
output shown in the bug.
gdb/testsuite/ChangeLog
2021-04-19 Tom Tromey <tromey@adacore.com>
PR gdb/27742:
* gdb.opt/inline-locals.exp: Update kfail patterns.
|
|
The .gdb_index was designed such that all data would be aligned.
Unfortunately, we neglected to require this alignment in the objcopy
instructions in the manual. As a result, in many cases, a .gdb_index
in the wild will not be properly aligned by mmap. This yields
undefined behavior, which is PR gdb/23743.
This patch fixes the bug by always assuming that the mapping is
unaligned, and using extract_unsigned_integer when needed. A new
helper class is introduced to make this less painful.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
PR gdb/23743:
* dwarf2/read.c (class offset_view): New.
(struct symbol_table_slot): Remove.
(struct mapped_index) <symbol_table, constant_pool>: Change type.
<symbol_name_index, symbol_vec_index>: New methods.
<symbol_name_slot_invalid, symbol_name_at, symbol_name_count>:
Rewrite.
(read_gdb_index_from_buffer): Update.
(struct dw2_symtab_iterator) <vec>: Change type.
(dw2_symtab_iter_init_common, dw2_symtab_iter_init)
(dw2_symtab_iter_next, dw2_expand_marked_cus): Update.
* dwarf2/index-write.c (class data_buf) <append_data>: Remove.
<append_array, append_offset>: New methods.
(write_hash_table, add_address_entry, write_gdbindex_1)
(write_debug_names): Update.
* dwarf2/index-common.h (byte_swap, MAYBE_SWAP): Remove.
|
|
If I try "save gdb-index" using the executable from
gdb.cp/cmpd-minsyms.exp, gdb will crash. This happens due to a
missing NULL check.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* dwarf2/index-write.c (write_psymtabs_to_index): Check
partial_symtabs.
gdb/testsuite/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/gdb-index-nodebug.exp: New file.
|
|
quick_symbol_functions::map_matching_symbols is only used by the Ada
code. Currently, it both expands certain psymtabs and then walks over
the full symtabs -- including any already-expanded ones -- calling a
callback.
It appears to work lazily as well, in that if the callback returns
false, iteration stops. However, only the psymtab implementation does
this; the DWARF index implementations are not lazy. It turns out,
though, that the only callback that is ever passed here never returns
false.
This patch simplifies this method by removing the callback. The
method is also renamed. In the new scheme, the caller is responsible
for walking the full symtabs, which removes some redundancy as well.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* psymtab.c (psymbol_functions::expand_matching_symbols): Rename
from map_matching_symbols. Change parameters.
* psympriv.h (struct psymbol_functions) <expand_matching_symbols>:
Rename from map_matching_symbols. Change parameters.
* dwarf2/read.c (struct dwarf2_gdb_index)
<expand_matching_symbols>: Rename from map_matching_symbols.
Change parameters.
(struct dwarf2_debug_names_index) <expand_matching_symbols>:
Rename from map_matching_symbols. Change parameters.
(dwarf2_gdb_index::expand_matching_symbols): Rename from
dw2_map_matching_symbols. Change parameters.
(dwarf2_gdb_index::expand_matching_symbols): Remove old
implementation.
(dwarf2_debug_names_index::expand_matching_symbols): Rename from
map_matching_symbols. Change parameters.
* objfiles.h (struct objfile) <expand_matching_symbols>: Rename
from map_matching_symbols. Change parameters.
* symfile-debug.c (objfile::expand_matching_symbols): Rename from
map_matching_symbols. Change parameters.
* ada-lang.c (map_matching_symbols): New function.
(add_nonlocal_symbols): Update.
|
|
This removes quick_symbol_functions::expand_symtabs_with_fullname,
replacing it with a call to expand_symtabs_matching. As with the
previous patches, the implementation is consolidated in the objfile
method.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* quick-symbol.h (struct quick_symbol_functions)
<expand_symtabs_with_fullname>: Remove.
* psymtab.c (psymbol_functions::expand_symtabs_with_fullname):
Remove.
* psympriv.h (struct psymbol_functions)
<expand_symtabs_with_fullname>: Remove.
* dwarf2/read.c (struct dwarf2_base_index_functions)
<expand_symtabs_with_fullname>: Remove.
(dwarf2_base_index_functions::expand_symtabs_with_fullname):
Remove.
* objfiles.h (struct objfile) <expand_symtabs_with_fullname>:
Update comment.
* symfile-debug.c (objfile::expand_symtabs_with_fullname):
Rewrite.
|
|
This removes quick_symbol_functions::expand_symtabs_for_function,
replacing it with a call to expand_symtabs_matching. As with the
previous patches, the implementation is consolidated in the objfile
method.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* symfile-debug.c (objfile::expand_symtabs_for_function):
Rewrite.
* quick-symbol.h (struct quick_symbol_functions)
<expand_symtabs_for_function>: Remove.
* psymtab.c (psymbol_functions::expand_symtabs_for_function):
Remove.
* psympriv.h (struct psymbol_functions)
<expand_symtabs_for_function>: Remove.
* objfiles.h (struct objfile) <expand_symtabs_for_function>:
Update comment.
* dwarf2/read.c (struct dwarf2_gdb_index)
<expand_symtabs_for_function>: Remove.
(struct dwarf2_debug_names_index) <expand_symtabs_for_function>:
Remove.
(find_slot_in_mapped_hash): Remove.
(dw2_symtab_iter_init_common): Merge with dw2_symtab_iter_init.
(dw2_symtab_iter_init): Remove one overload.
(dwarf2_gdb_index::expand_symtabs_for_function)
(dwarf2_debug_names_index::expand_symtabs_for_function): Remove.
|
|
This replaces quick_symbol_functions::map_symtabs_matching_filename
with a call to expand_symtabs_matching. As with the previous patch,
rather than update all callers, the implementation is consolidated in
objfile::map_symtabs_matching_filename.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* symfile-debug.c (objfile::map_symtabs_matching_filename):
Rewrite.
* quick-symbol.h (struct quick_symbol_functions)
<map_symtabs_matching_filename>: Remove.
* psymtab.c (partial_map_expand_apply)
(psymbol_functions::map_symtabs_matching_filename): Remove.
* psympriv.h (struct psymbol_functions)
<map_symtabs_matching_filename>: Remove.
* objfiles.h (struct objfile) <map_symtabs_matching_filename>:
Update comment.
* dwarf2/read.c (struct dwarf2_base_index_functions)
<map_symtabs_matching_filename>: Remove.
(dw2_map_expand_apply)
(dwarf2_base_index_functions::map_symtabs_matching_filename):
Remove.
|
|
This removes quick_symbol_functions, replacing it with calls to
expand_symtabs_matching. Because the replacement is somewhat verbose,
objfile::lookup_symbol is not removed. This consolidates some
duplicated code into this one spot.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* symfile-debug.c (objfile::lookup_symbol): Rewrite.
* quick-symbol.h (struct quick_symbol_functions) <lookup_symbol>:
Remove.
* psymtab.c (psymbol_functions::lookup_symbol): Remove.
* psympriv.h (struct psymbol_functions) <lookup_symbol>: Remove.
* objfiles.h (struct objfile) <lookup_symbol>: Add comment.
* dwarf2/read.c (struct dwarf2_gdb_index) <lookup_symbol>:
Remove.
(struct dwarf2_debug_names_index) <lookup_symbol>: Remove.
(dwarf2_gdb_index::lookup_symbol)
(dwarf2_debug_names_index::lookup_symbol): Remove.
|
|
Currently, expand_symtabs_matching only accepts a search_domain
parameter. However, lookup_symbol uses a domain_enum instead, and the
two, confusingly, do quite different things -- one cannot emulate the
other. So, this patch adds a domain_enum parameter to
expand_symtabs_matching, with UNDEF_DOMAIN used as a wildcard.
This is another step toward replacing lookup_symbol with
expand_symtabs_matching.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* symtab.c (global_symbol_searcher::expand_symtabs): Update.
* symmisc.c (maintenance_expand_symtabs): Update.
* symfile.c (expand_symtabs_matching): Update.
* symfile-debug.c (objfile::expand_symtabs_matching): Add 'domain'
parameter.
* quick-symbol.h (struct quick_symbol_functions)
<expand_symtabs_matching>: Add 'domain' parameter.
* psymtab.c (recursively_search_psymtabs)
(psymbol_functions::expand_symtabs_matching): Add 'domain'
parameter.
* psympriv.h (struct psymbol_functions) <expand_symtabs_matching>:
Add 'domain' parameter.
* objfiles.h (struct objfile) <expand_symtabs_matching>: Add
'domain' parameter.
* linespec.c (iterate_over_all_matching_symtabs): Update.
* dwarf2/read.c (struct dwarf2_gdb_index)
<expand_symtabs_matching>: Add 'domain' parameter.
(struct dwarf2_debug_names_index) <expand_symtabs_matching>: Add
'domain' parameter.
(dw2_expand_symtabs_matching)
(dwarf2_gdb_index::expand_symtabs_matching)
(dw2_debug_names_iterator)
(dwarf2_debug_names_index::expand_symtabs_matching): Add 'domain'
parameter.
|
|
This adds a block search flags parameter to expand_symtabs_matching.
All callers are updated to search both the static and global blocks,
as that was the implied behavior before this patch.
This is a step toward replacing lookup_symbol with
expand_symtabs_matching.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* symtab.c (global_symbol_searcher::expand_symtabs)
(default_collect_symbol_completion_matches_break_on): Update.
* symmisc.c (maintenance_expand_symtabs): Update.
* symfile.h (expand_symtabs_matching): Add search_flags
parameter.
* symfile.c (expand_symtabs_matching): Add search_flags
parameter.
* symfile-debug.c (objfile::expand_symtabs_matching): Add
search_flags parameter.
* quick-symbol.h (struct quick_symbol_functions)
<expand_symtabs_matching>: Add search_flags parameter.
* python/py-symbol.c (gdbpy_lookup_static_symbols): Update.
* psymtab.c (recursively_search_psymtabs)
(psymbol_functions::expand_symtabs_matching): Add search_flags
parameter.
* psympriv.h (struct psymbol_functions) <expand_symtabs_matching>:
Add search_flags parameter.
* objfiles.h (struct objfile) <expand_symtabs_matching>: Add
search_flags parameter.
* linespec.c (iterate_over_all_matching_symtabs): Update.
* dwarf2/read.c (struct dwarf2_gdb_index)
<expand_symtabs_matching>: Add search_flags parameter.
(struct dwarf2_debug_names_index) <expand_symtabs_matching>: Add
search_flags parameter.
(dw2_map_matching_symbols): Update.
(dw2_expand_marked_cus, dw2_expand_symtabs_matching)
(dwarf2_gdb_index::expand_symtabs_matching): Add search_flags
parameter.
(dw2_debug_names_iterator): Change block_index to search flags.
<m_block_index>: Likewise.
(dw2_debug_names_iterator::next)
(dwarf2_debug_names_index::lookup_symbol)
(dwarf2_debug_names_index::expand_symtabs_for_function)
(dwarf2_debug_names_index::map_matching_symbols)
(dwarf2_debug_names_index::map_matching_symbols): Update.
(dwarf2_debug_names_index::expand_symtabs_matching): Add
search_flags parameter.
* ada-lang.c (ada_add_global_exceptions)
(collect_symbol_completion_matches): Update.
|
|
This changes expand_symtabs_exp_notify_ftype to return bool, and
updates all the uses. Now, if the notification function returns
false, the call is short-circuited and stops examining symtabs. This
is a step toward replacing map_symtabs_matching_filename with
expand_symtabs_matching.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* symtab.c (default_collect_symbol_completion_matches_break_on):
Update.
* symfile.h (expand_symtabs_matching): Return bool.
* symfile.c (expand_symtabs_matching): Return bool.
* symfile-debug.c (objfile::expand_symtabs_matching): Return
bool.
* quick-symbol.h (expand_symtabs_exp_notify_ftype): Return bool.
(struct quick_symbol_functions) <expand_symtabs_matching>: Return
bool.
* psymtab.c (psymbol_functions::expand_symtabs_matching): Return
bool.
* psympriv.h (struct psymbol_functions)
<expand_symtabs_matching>: Return bool.
* objfiles.h (struct objfile) <expand_symtabs_matching>: Return
bool.
* dwarf2/read.c (struct dwarf2_gdb_index)
<expand_symtabs_matching>: Return bool.
(struct dwarf2_debug_names_index) <expand_symtabs_matching>:
Return bool.
(dw2_expand_symtabs_matching_symbol): Return bool.
(dw2_expand_symtabs_matching_one, dw2_expand_marked_cus)
(dw2_expand_symtabs_matching)
(dwarf2_gdb_index::expand_symtabs_matching)
(dwarf2_debug_names_index::expand_symtabs_matching)
(dwarf2_debug_names_index::expand_symtabs_matching): Return bool.
|
|
This adds block_search_flags, a flag enum. This will be used to by
certain search functions so that the caller can control which blocks
are searched more precisely.
gdb/ChangeLog
2021-04-17 Tom Tromey <tom@tromey.com>
* quick-symbol.h (enum block_search_flag_values): New.
(block_search_flags): New enum flags type.
|
|
The Rust expression parser was written to construct its own AST, then
lower this to GDB expressions. I did this primarily because the old
expressions were difficult to work with; after rewriting those, I
realized I could remove the AST from the Rust parser.
After looking at this, I realized it might be simpler to rewrite the
parser. This patch reimplements it as a recursive-descent parser. I
kept a fair amount of the existing code -- the lexer is pulled in
nearly unchanged.
There are several benefits to this approach:
* The parser is shorter now (from 2882 LOC to 2351).
* The parser is just ordinary C++ code that can be debugged in the
usual way.
* Memory management in the parser is now straightforward, as
parsing methods simply return a unique pointer or vector.
This required a couple of minor changes to the test suite, as some
errors have changed.
While this passes the tests, it's possible there are lurking bugs,
particularly around error handling.
gdb/ChangeLog
2021-04-16 Tom Tromey <tom@tromey.com>
* rust-parse.c: New file.
* rust-exp.y: Remove.
* Makefile.in (COMMON_SFILES): Add rust-parse.c.
(SFILES): Remove rust-exp.y.
(YYFILES, local-maintainer-clean): Remove rust-exp.c.
gdb/testsuite/ChangeLog
2021-04-16 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Change error text.
* gdb.rust/expr.exp: Change error text.
|
|
The Rust test case simple.exp does:
print slice as &[i32][0]
However, this is a syntax error in Rust. Parens are needed around the
"as".
gdb/testsuite/ChangeLog
2021-04-16 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Add parens to 'as' test.
|
|
By default, when using the -g switch, avr-gcc generates stabs debug
information. I think it would make more sense to test GDB against DWARF
information, because stabs is obsolete by now, and nobody work on it.
So change the simavr board to pass -gdwarf-4 as the debug flag.
The downside is that users are probably more likely to use just -g, so
we don't test GDB the same way as users are likely to use it. But in
this case, if somebody comes and asks for help with GDB for AVR, I
suggest we encourage them to use -gdwarf-4.
I can't give stats about how that changes test results, because the
testsuite is too broken. There is an internal error that happens quite
frequently that needs to be investigated:
/home/simark/src/wt/avr/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_kind::ADDR' failed.
I sent a question on the gcc mailing list, asking why stabs is the
default:
https://gcc.gnu.org/pipermail/gcc/2021-April/235309.html
gdb/testsuite/ChangeLog:
* boards/simavr.exp: Set debug_flags.
Change-Id: I70e471fad3a79ab1d79d13dda8436bb9eb666e0a
|
|
Even if the DWARF information contains a bfloat16 base type (__bf16), a
variable of such type will still be printed using the IEEE half float format,
which is wrong.
This patch teaches GDB how to pick the bfloat16 format for __bf16 types in
DWARF (based on the base type name) and uses IEEE half float for all the other
16-bit float formats.
Tested on aarch64-linux/x86_64-linux.
OK?
gdb/ChangeLog:
2021-04-16 Luis Machado <luis.machado@linaro.org>
* arch-utils.c (default_floatformat_for_type): Handle bfloat16.
gdb/testsuite:
2021-04-16 Luis Machado <luis.machado@linaro.org>
* gdb.dwarf2/dw2-bfloat16.exp: New file.
|
|
gdb/ChangeLog:
* fbsd-nat.c (fbsd_lwp_debug_printf, fbsd_nat_debug_printf): New,
use throughout file.
|
