| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
These arches use cgen memory functions, so make sure to include the
header in the modules.
|
|
Various files were not including the relevant headers, or some funcs
were missing prototypes entirely, leading to mismatch between the
actual definition of the functions. Add includes to a few places and
fix the broken functions that are uncovered as a result. Fixing some
compile warnings (e.g. missing prototypes) often find real bugs.
|
|
The cgen trace macros are a bit ugly in that they specify a series of
format strings & arguments in a single call. This means we pass a
non-literal string to printf and the compiler warns about it. Use
the diagnostic macros to suppress that in this one place.
|
|
If the user passed in values outside the range of [0, MAX_NR_PROCESSORS),
it would cause the code to access out-of-bind engine function pointers.
Add some asserts to catch that and to fix the related compiler warnings.
|
|
This helps the compiler process calls to these functions and emit
warnings about mismatched format arguments.
|
|
Shouldn't be any functional changes here.
|
|
This fixes missing prototype warnings, and guarantees the prototypes
stay in sync with the function definitions. One of the macros had
fallen out by declaring the wrong return type.
|
|
This fixes missing prototype warnings, and guarantees the prototypes
stay in sync with the function definitions.
|
|
These prototype blocks are not normally used, so they've fallen out
of sync with the actual function definitions. Resync them all.
|
|
Since the value variable usually has an incompatible type for the wide
variety of types it is printed as, add explicit casts to them all.
|
|
|
|
Move the unique library tests to the common code so we can delete
the erc32 configure logic entirely.
|
|
This reduces the unique logic in bfin/configure to make it easier to
(eventually) unify it entirely.
|
|
|
|
Use the set_show_commands objects returned by the add_setshow functions
in add_setshow_generic. This lets us avoid looking up the commands
after creating them, instead using the return objects directly.
Make add_setshow_generic return a set_show_commands object, which is a
bit nicer than returning both commands by parameter.
Finally, store using that object in param_smob.
Equivalent of 7bd22f56a3cf ("gdb/python: use return values of
add_setshow functions in add_setshow_generic"), but for guile.
gdb/ChangeLog:
* guile/scm-param.c (struct param_smob) <set_command,
show_command>: Remove.
<commands>: New.
(pascm_is_valid): Adjust.
(add_setshow_generic): Use return values of add_setshow
functions, return a set_show_commands.
(gdbscm_register_parameter_x): Adjust.
Change-Id: I18ed9e7dd5646529491c86749a5cb20763acd1f0
|
|
I propose removing the context parameter from add_setshow_enum_cmd. It
was useful before add_setshow_enum_cmd returned both created commands,
as the caller couldn't easily set the context itself. But now, I think
it's fine to just let the caller do it.
gdb/ChangeLog:
* command.h (add_setshow_enum_cmd): Remove context parameter.
* cli/cli-decode.c (add_setshow_enum_cmd): Likewise, and don't
set context.
* cli/cli-style.c (cli_style_option::add_setshow_commands): Set
context here.
Change-Id: I377c4e6820ec9d5069492ed28f4cba342ce1336e
|
|
If something tries to set a context pointer on a cmd_list_element and
m_context is not nullptr, it's likely that two parts of the code are
trying to set different contexts, and one will overwrite the other.
This is almost guaranteed to lead to bad behavior or a crash, as one of
the spots will not be using the data it expects. This happened to me
during development, so I think having this assert would be useful to
catch this problem earlier.
gdb/ChangeLog:
* cli/cli-decode.h (struct cmd_list_element) <set_context>: Add
assert.
Change-Id: I1f2e9fda1bf2bec1b732c9b90e7d7910a97f2ac6
|
|
Straightforward replacement of get_cmd_context / set_cmd_context with
cmd_list_element methods.
gdb/ChangeLog:
* cli/cli-decode.h (struct cmd_list_element) <set_context,
context>: New.
<context>: Rename to...
<m_context>: ... this.
* cli/cli-decode.c (set_cmd_context, get_cmd_context): Remove.
* command.h (set_cmd_context, get_cmd_context): Remove, use
cmd_list_element::set_context and cmd_list_element::context
everywhere instead.
Change-Id: I5016b0079014e3f17d1aa449ada7954473bf2b5d
|
|
|
|
Currently the 'info sources' command lists all of the known source
files together, regardless of their source, e.g. here is a session
debugging a test application that makes use of a shared library:
(gdb) info sources
Source files for which symbols have been read in:
/tmp/info-sources/test.c, /usr/include/stdc-predef.h,
/tmp/info-sources/header.h, /tmp/info-sources/helper.c
Source files for which symbols will be read in on demand:
(gdb)
In this commit I change the format of the 'info sources' results so
that the results are grouped by the object file that uses that source
file. Here's the same session with the new output format:
(gdb) info sources
/tmp/info-sources/test.x:
/tmp/info-sources/test.c, /usr/include/stdc-predef.h,
/tmp/info-sources/header.h
/lib64/ld-linux-x86-64.so.2:
(Objfile has no debug information.)
system-supplied DSO at 0x7ffff7fcf000:
(Objfile has no debug information.)
/tmp/info-sources/libhelper.so:
/tmp/info-sources/helper.c, /usr/include/stdc-predef.h,
/tmp/info-sources/header.h
/lib64/libc.so.6:
(Objfile has no debug information.)
(gdb)
Notice that in the new output some source files are repeated,
e.g. /tmp/info-sources/header.h, as multiple objfiles use this source
file.
Further, some object files are tagged with the message '(Objfile has
no debug information.)', it is also possible to see the message '(Full
debug information has not yet been read for this file.)', which is
printed when some symtabs within an objfile have not yet been
expanded.
All of the existing regular expression based filtering still works.
An original version of this patch added the new format as an option to
'info sources', however, it was felt that the new layout was so much
better than the old style that GDB should just switch to the new
result format completely.
gdb/ChangeLog:
* NEWS: Mention changes to 'info sources'.
* symtab.c (info_sources_filter::print): Delete.
(struct output_source_filename_data) <print_header>: Delete
declaration. <printed_filename_p>: New member function.
(output_source_filename_data::print_header): Delete.
(info_sources_worker): Update group-by-objfile style output to
make it CLI suitable, simplify non-group-by-objfile now this is
only used from the MI.
(info_sources_command): Make group-by-objfile be the default for
CLI info sources command.
* symtab.h (struct info_sources_filter) <print>: Delete.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new output format for 'info
sources'.
gdb/testsuite/ChangeLog:
* gdb.base/info_sources_2-header.h: New file.
* gdb.base/info_sources_2-lib.c: New file.
* gdb.base/info_sources_2-test.c: New file.
* gdb.base/info_sources_2.exp: New file.
|
|
This commit adds a new option '--group-by-objfile' to the MI command
-file-list-exec-source-files. With this option the output format is
changed; instead of a single list of source files the results are now
a list of objfiles. For each objfile all of the source files
associated with that objfile are listed.
Here is an example of the new output format taken from the
documentation (the newlines are added just for readability):
-file-list-exec-source-files --group-by-objfile
^done,files=[{filename="/tmp/info-sources/test.x",
debug-info="fully-read",
sources=[{file="test.c",
fullname="/tmp/info-sources/test.c",
debug-fully-read="true"},
{file="/usr/include/stdc-predef.h",
fullname="/usr/include/stdc-predef.h",
debug-fully-read="true"},
{file="header.h",
fullname="/tmp/info-sources/header.h",
debug-fully-read="true"}]},
{filename="/lib64/ld-linux-x86-64.so.2",
debug-info="none",
sources=[]},
{filename="system-supplied DSO at 0x7ffff7fcf000",
debug-info="none",
sources=[]},
{filename="/tmp/info-sources/libhelper.so",
debug-info="fully-read",
sources=[{file="helper.c",
fullname="/tmp/info-sources/helper.c",
debug-fully-read="true"},
{file="/usr/include/stdc-predef.h",
fullname="/usr/include/stdc-predef.h",
debug-fully-read="true"},
{file="header.h",
fullname="/tmp/info-sources/header.h",
debug-fully-read="true"}]},
{filename="/lib64/libc.so.6",
debug-info="none",
sources=[]}]
In the above output the 'debug-info' field associated with each
objfile will have one of the values 'none', 'partially-read', or
'fully-read'. For example, /lib64/libc.so.6 has the value 'none',
this indicates that this object file has no debug information
associated with it, unsurprisingly then, the sources list of this
object file is empty.
An object file that was compiled with debug, for example
/tmp/info-sources/libhelper.so, has the value 'fully-read' above
indicating that this object file does have debug information, and the
information is fully read into GDB. At different times this field
might have the value 'partially-read' indicating that that the object
file has debug information, but it has not been fully read into GDB
yet.
Source files can appear at most once for any single objfile, but can
appear multiple times in total, if the same source file is part of
multiple objfiles, for example /tmp/info-sources/header.h in the above
output.
The new output format is hidden behind a command option to ensure that
the default output is unchanged, this ensures backward compatibility.
The behaviour of the CLI "info sources" command is unchanged after
this commit.
gdb/ChangeLog:
* NEWS: Mention additions to -file-list-exec-source-files.
* mi/mi-cmd-file.c (mi_cmd_file_list_exec_source_files): Add
--group-by-objfile option.
* symtab.c (isrc_flag_option_def): Rename to...
(isrc_match_flag_option_def): ...this.
(info_sources_option_defs): Rename to...
(info_sources_match_option_defs): ...this, and update to rename of
isrc_flag_option_def.
(struct filename_grouping_opts): New struct.
(isrc_grouping_flag_option_def): New type.
(info_sources_grouping_option_defs): New static global.
(make_info_sources_options_def_group): Update to return two option
groups.
(info_sources_command_completer): Update for changes to
make_info_sources_options_def_group.
(info_sources_worker): Add extra parameter, use this to display
alternative output format.
(info_sources_command): Pass extra parameter to
info_sources_worker.
(_initialize_symtab): Update for changes to
make_info_sources_options_def_group.
* symtab.h (info_sources_worker): Add extra parameter.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI File Commands): Document --group-by-objfile
extension for -file-list-exec-source-files.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-info-sources.exp: Add additional tests.
|
|
This commit extends the existing MI command
-file-list-exec-source-files to provide the same regular expression
based filtering that the equivalent CLI command "info sources"
provides.
The new command syntax is:
-file-list-exec-source-files [--basename | --dirname] [--] [REGEXP]
All options are optional, which ensures the command is backward
compatible.
As part of this work I have unified the CLI and MI code.
As a result of the unified code I now provide additional information
in the MI command output, there is now a new field 'debug-fully-read'
included with each source file. This field which has the values
'true' or 'false', indicates if the source file is from a compilation
unit that has had its debug information fully read. However, as this
is additional information, a well written front-end should just ignore
this field if it doesn't understand it, so things should still be
backward compatible.
gdb/ChangeLog:
* NEWS: Mention additions to -file-list-exec-source-files.
* mi/mi-cmd-file.c (print_partial_file_name): Delete.
(mi_cmd_file_list_exec_source_files): Rewrite to handle command
options, and make use of info_sources_worker.
* symtab.c (struct info_sources_filter): Moved to symtab.h.
(info_sources_filter::print): Take uiout argument, produce output
through uiout.
(struct output_source_filename_data)
<output_source_filename_data>: Take uiout argument, store into
m_uiout. <output>: Rewrite comment, add additional arguments to
declaration. <operator()>: Send more arguments to
output. <m_uiout>: New member variable.
(output_source_filename_data::output): Take extra arguments,
produce output through m_uiout, and structure for MI.
(output_source_filename_data::print_header): Produce output
through m_uiout.
(info_sources_worker): New function, the implementation is taken
from info_sources_command, but modified so produce output through
a ui_out.
(info_sources_command): The second half of this function has gone
to become info_sources_worker.
* symtab.h (struct info_sources_filter): Moved from symtab.c, add
extra parameter to print member function.
(info_sources_worker): Declare.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI File Commands): Document extensions to
-file-list-exec-source-files.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-filename.exp: Update expected results.
* gdb.mi/mi-file.exp: Likewise.
* gdb.mi/mi-info-sources-base.c: New file.
* gdb.mi/mi-info-sources.c: New file.
* gdb.mi/mi-info-sources.exp: New file.
|
|
In a future commit I'm going to be making some changes to the 'info
sources' command. While looking at the code I noticed that things
could be improved by making struct output_source_filename_data more
C++ like (private member variables, and more member functions).
That's what this commit does.
The 'info sources' filename filtering is split out into a separate
class in this commit. In a future commit this new filter
class (info_sources_filter) will move into the header file and be used
from the MI code.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* symtab.c (struct info_sources_filter): New.
(info_sources_filter::info_sources_filter): New function.
(info_sources_filter::matches): New function.
(info_sources_filter::print): New function.
(struct filename_partial_match_opts): Moved to later in the file
and update the comment.
(struct output_source_filename_data)
<output_source_filename_data>: New constructor. <regexp>: Delete,
this is now in info_sources_filter. <c_regexp>: Delete, this is
now in info_sources_filter. <reset_output>: New member function.
<filename_seen_cache>: Rename to m_filename_seen_cache, change
from being a pointer, to being an actual object. <first>: Rename
to m_first. <print_header>: New member function. <partial_match>:
Delete.
(output_source_filename_data::output): Update now
m_filename_seen_cache is no longer a pointer, and for other member
variable name changes. Add a header comment.
(print_info_sources_header): Renamed to...
(output_source_filename_data::print_header): ...this. Update now
it's a member function and to take account of member variable
renaming.
(info_sources_command): Add a header comment, delete stack local
filename_seen_cache, initialization of output_source_filename_data
is now done by the constructor. Call print_header member function
instead of print_info_sources_header, call reset_output member
function instead of manually performing the reset.
|
|
Adds a new function to the quick_symbol_functions API to let us know
if there are any unexpanded symbols. This functionality is required
by a later commit. After this commit the functionality is unused, and
untested.
The new function objfile::has_unexpanded_symtabs is added to the
symfile-debug.c file which is a little strange, but this
is (currently) where many of the other objfile::* functions (that call
onto the quick_symbol_functions) are defined, so I'm reluctant to
break this pattern.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dwarf2/read.c (struct dwarf2_base_index_functions)
<has_unexpanded_symtabs>: Declare.
(dwarf2_base_index_functions::has_unexpanded_symtabs): Define new
function.
* objfiles.h (struct objfile) <has_unexpanded_symtabs>: Declare.
* psympriv.h (struct psymbol_functions) <has_unexpanded_symtabs>:
Declare.
* psymtab.c (psymbol_functions::has_unexpanded_symtabs): Define
new function.
* quick-symbol.h (struct quick_symbol_functions)
<has_unexpanded_symtabs>: Declare.
* symfile-debug.c (objfile::has_unexpanded_symtabs): Define new
function.
|
|
In this commit:
commit 7022349d5c86bae74b49225515f42d2e221bd368
Date: Mon Sep 4 20:21:13 2017 +0100
Stop assuming no-debug-info functions return int
A new if case was added to call_function_by_hand_dummy to decide if a
function should be considered prototyped or not. Previously the code
was structured like this:
if (COND_1)
ACTION_1
else if (COND_2)
ACTION_2
else
ACTION_3
With the new block the code now looks like this:
if (COND_1)
ACTION_1
if (NEW_COND)
NEW_ACTION
else if (COND_2)
ACTION_2
else
ACTION_3
Notice the new block was added as and 'if' not 'else if'. I'm running
into a case where GDB executes ACTION_1 and then ACTION_2. Prior to
the above commit GDB would only have executed ACTION_1.
The actions in the code in question are trying to figure out if a
function should be considered prototyped or not. When a function is
not prototyped some arguments will be coerced, e.g. floats to doubles.
The COND_1 / ACTION_1 are a very broad, any member function should be
considered prototyped, however, after the above patch GDB is now
executing the later ACTION_2 which checks to see if the function's
type has the 'prototyped' flag set - this is not the case for the
member functions I'm testing, and so GDB treats the function as
unprototyped and casts the float argument to a double.
I believe that adding the new check as 'if' rather than 'else if' was
a mistake, and so in this commit I add in the missing 'else'.
gdb/ChangeLog:
* infcall.c (call_function_by_hand_dummy): Add missing 'else' when
setting prototyped flag.
gdb/testsuite/ChangeLog:
* gdb.cp/method-call-in-c.cc (struct foo_type): Add static member
function static_method.
(global_var): New global.
(main): Use new static_method to ensure it is compiled in.
* gdb.cp/method-call-in-c.exp: Test calls to static member
function.
|
|
Following on from the previous commit, this commit changes the API of
value_struct_elt to take gdb::optional<gdb::array_view<value *>>
instead of a pointer to the gdb::array_view.
This makes the optional nature of the array_view parameter explicit.
This commit is purely a refactoring commit, there should be no user
visible change after this commit.
I have deliberately kept this refactor separate from the previous two
commits as this is a more extensive change, and I'm not 100% sure that
using gdb::optional for the parameter type, instead of a pointer, is
going to be to everyone's taste. If there's push back on this patch
then this one can be dropped from the series.
gdb/ChangeLog:
* ada-lang.c (desc_bounds): Use '{}' instead of NULL to indicate
an empty gdb::optional when calling value_struct_elt.
(desc_data): Likewise.
(desc_one_bound): Likewise.
* eval.c (structop_base_operation::evaluate_funcall): Pass
gdb::array_view, not a gdb::array_view* to value_struct_elt.
(eval_op_structop_struct): Use '{}' instead of NULL to indicate
an empty gdb::optional when calling value_struct_elt.
(eval_op_structop_ptr): Likewise.
* f-lang.c (fortran_structop_operation::evaluate): Likewise.
* guile/scm-value.c (gdbscm_value_field): Likewise.
* m2-lang.c (eval_op_m2_high): Likewise.
(eval_op_m2_subscript): Likewise.
* opencl-lang.c (opencl_structop_operation::evaluate): Likewise.
* python/py-value.c (valpy_getitem): Likewise.
* rust-lang.c (rust_val_print_str): Likewise.
(rust_range): Likewise.
(rust_subscript): Likewise.
(eval_op_rust_structop): Likewise.
(rust_aggregate_operation::evaluate): Likewise.
* valarith.c (value_user_defined_op): Likewise.
* valops.c (search_struct_method): Change parameter type, update
function body accordingly, and update header comment.
(value_struct_elt): Change parameter type, update function body
accordingly.
* value.h (value_struct_elt): Update declaration.
|
|
After the previous commit, this commit updates the value_struct_elt
function to take an array_view rather than a NULL terminated array of
values.
The requirement for a NULL terminated array of values actually stems
from typecmp, so the change from an array to array_view needs to be
propagated through to this function.
While making this change I noticed that this fixes another bug, in
value_x_binop and value_x_unop GDB creates an array of values which
doesn't have a NULL at the end. An array_view of this array is passed
to value_user_defined_op, which then unpacks the array_view and passed
the raw array to value_struct_elt, but only if the language is not
C++.
As value_x_binop and value_x_unop can only request member functions
with the names of C++ operators, then most of the time, assuming the
inferior is not a C++ program, then GDB will not find a matching
member function with the call to value_struct_elt, and so typecmp will
never be called, and so, GDB will avoid undefined behaviour.
However, it is worth remembering that, when GDB's language is set to
"auto", the current language is selected based on the language of the
current compilation unit. As C++ programs usually link against libc,
which is written in C, then, if the inferior is stopped in libc GDB
will set the language to C. And so, it is possible that we will end
up using value_struct_elt to try and lookup, and match, a C++
operator. If this occurs then GDB will experience undefined
behaviour.
I have extended the test added in the previous commit to also cover
this case.
Finally, this commit changes the API from passing around a pointer to
an array to passing around a pointer to an array_view. The reason for
this is that we need to be able to distinguish between the cases where
we call value_struct_elt with no arguments, i.e. we are looking up a
struct member, but we either don't have the arguments we want to pass
yet, or we don't expect there to be any need for GDB to use the
argument types to resolve any overloading; and the second case where
we call value_struct_elt looking for a function that takes no
arguments, that is, the argument list is empty.
NOTE: While writing this I realise that if we pass an array_view at
all then it will always have at least one item in it, the `this'
pointer for the object we are planning to call the method on. So we
could, I guess, pass an empty array_view to indicate the case where we
don't know anything about the arguments, and when the array_view is
length 1 or more, it means we do have the arguments. However, though
we could do this, I don't think this would be better, the length 0 vs
length 1 difference seems a little too subtle, I think that there's a
better solution...
I think a better solution would be to wrap the array_view in a
gdb::optional, this would make the whole, do we have an array view or
not question explicit.
I haven't done this as part of this commit as making that change is
much more extensive, every user of value_struct_elt will need to be
updated, and as this commit already contains a bug fix, I wanted to
keep the large refactoring in a separate commit, so, check out the
next commit for the use of gdb::optional.
gdb/ChangeLog:
PR gdb/27994
* eval.c (structop_base_operation::evaluate_funcall): Pass
array_view instead of array to value_struct_elt.
* valarith.c (value_user_defined_op): Likewise.
* valops.c (typecmp): Change parameter type from array pointer to
array_view. Update header comment, and update body accordingly.
(search_struct_method): Likewise.
(value_struct_elt): Likewise.
* value.h (value_struct_elt): Update declaration.
gdb/testsuite/ChangeLog:
PR gdb/27994
* gdb.cp/method-call-in-c.cc (struct foo_type): Add operator+=,
change initial value of var member variable.
(main): Make use of foo_type's operator+=.
* gdb.cp/method-call-in-c.exp: Test use of operator+=.
|
|
This regression, as it is exposed by the test added in this commit,
first became noticable with this commit:
commit d182f2797922a305fbd1ef6a483cc39a56b43e02
Date: Mon Mar 8 07:27:57 2021 -0700
Convert c-exp.y to use operations
But, this commit only added converted the C expression parser to make
use of code that was added in this commit:
commit a00b7254fb614af557de7ae7cc0eb39a0ce0e408
Date: Mon Mar 8 07:27:57 2021 -0700
Implement function call operations
And it was this second commit that actually introduced the bugs (there
are two).
In structop_base_operation::evaluate_funcall we build up an argument
list in the vector vals. Later in this function the argument list
might be passed to value_struct_elt.
Prior to commit a00b7254fb614 the vals vector (or argvec as it used to
be called) stored the value for the function callee in the argvec at
index 0. This 'callee' value is what ends up being passed to
evaluate_subexp_do_call, and represents the function to be called, the
value contents are the address of the function, and the value type is
the function signature. The remaining items held in the argvec were
the values to pass to the function. For a non-static member function
the `this' pointer would be at index 1 in the array.
After commit a00b7254fb614 this callee value is now held in a separate
variable, not the vals array. So, for non-static member functions,
the `this' pointer is now at index 0, with any other arguments after
that.
What this means is that previous, when we called value_struct_elt we
would pass the address of argvec[1] as this was the first argument.
But now we should be passing the address of vals[0]. Unfortunately,
we are still passing vals[1], effectively skipping the first
argument.
The second issue is that, prior to commit a00b7254fb614, the argvec
array was NULL terminated. This is required as value_struct_elt
calls search_struct_method, which calls typecmp, and typecmp requires
that the array have a NULL at the end.
After commit a00b7254fb614 this NULL has been lost, and we are
therefore violating the API requirements of typecmp.
This commit fixes both of these regressions. I also extended the
header comments on search_struct_method and value_struct_elt to make
it clearer that the array required a NULL marker at the end.
You will notice in the test attached to this commit that I test
calling a non-static member function, but not calling a static member
function. The reason for this is that calling static member functions
is currently broken due to a different bug. That will be fixed in a
later patch in this series, at which time I'll add a test for calling
a static member function.
gdb/ChangeLog:
PR gdb/27994
* eval.c (structop_base_operation::evaluate_funcall): Add a
nullptr to the end of the args array, which should not be included
in the argument array_view. Pass all the arguments through to
value_struct_elt.
* valops.c (search_struct_method): Update header comment.
(value_struct_elt): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/27994
* gdb.cp/method-call-in-c.cc: New file.
* gdb.cp/method-call-in-c.exp: New file.
|
|
When GCC emits .debug_aranges, it adds padding to align the contents
to two times the address size. GCC has done this for many years --
but there is nothing in the DWARF standard that says this should be
done, and LLVM does not seem to add this padding.
It's simple to detect if the padding exists, though: if the contents
of one .debug_aranges CU (excluding the header) are not a multiple of
the alignment that GCC uses, then anything extra must be padding.
This patch changes gdb to correctly read both styles. It removes the
requirement that the padding bytes be zero, as this seemed
unnecessarily pedantic to me.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (create_addrmap_from_aranges): Change padding
logic.
gdb/testsuite/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (add_gdb_index, ensure_gdb_index): Add "style"
parameter.
* gdb.rust/dwindex.exp: New file.
* gdb.rust/dwindex.rs: New file.
|
|
dwarf2_cu has a 'language' value, but dwarf2_per_cu_data also holds a
value of this same type. There doesn't seem to be any reason to keep
two copies of this value. This patch removes the field from
dwarf2_cu, and arranges to set the value in the per-CU object instead.
Note that the value must still be set when expanding the full CU.
This is needed because the CUs will not be scanned when a DWARF index
is in use.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (process_psymtab_comp_unit): Don't set 'lang'.
(scan_partial_symbols, partial_die_parent_scope)
(add_partial_symbol, add_partial_subprogram)
(compute_delayed_physnames, rust_union_quirks)
(process_full_comp_unit, process_full_type_unit)
(process_imported_unit_die, process_die, dw2_linkage_name)
(dwarf2_compute_name, dwarf2_physname, read_import_statement)
(read_file_scope, queue_and_load_dwo_tu, read_func_scope)
(read_variable, dwarf2_get_subprogram_pc_bounds)
(dwarf2_attach_fields_to_type, dwarf2_add_member_fn)
(dwarf2_attach_fn_fields_to_type)
(quirk_ada_thick_pointer_struct, read_structure_type)
(handle_struct_member_die, process_structure_scope)
(read_array_type, read_array_order, prototyped_function_p)
(read_subroutine_type, dwarf2_init_complex_target_type)
(read_base_type, read_subrange_type, read_unspecified_type)
(load_partial_dies, partial_die_info::fixup, set_cu_language)
(new_symbol, need_gnat_info, determine_prefix, typename_concat)
(dwarf2_canonicalize_name, follow_die_offset)
(prepare_one_comp_unit): Update.
* dwarf2/cu.c (dwarf2_cu::start_symtab): Update.
|
|
The DWARF reader currently sets the CU's language in two different
spots. It is primarily done in prepare_one_comp_unit, but
read_file_scope also checks the producer and may change the language
based on the result.
This patch consolidates all language-setting into
prepare_one_comp_unit. set_cu_language is renamed and changed not to
set language_defn; instead that is done in prepare_one_comp_unit after
the correct language enum value is chosen.
This fixes a minor latent bug, which is that read_file_scope could set
the language enum value to language_opencl, but then neglected to
reset language_defn in this case.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_file_scope): Don't call set_cu_language.
(dwarf_lang_to_enum_language): Rename from set_cu_language. Don't
set language_defn. Handle DW_LANG_OpenCL.
(prepare_one_comp_unit): Check producer and set language_defn.
|
|
This commit adds initial support for catchpoints to the python
breakpoint API.
This commit adds a BP_CATCHPOINT constant which corresponds to
GDB's internal bp_catchpoint. The new constant is documented in the
manual.
The user can't create breakpoints with type BP_CATCHPOINT after this
commit, but breakpoints that already exist, obtained with the
`gdb.breakpoints` function, can now have this type. Additionally,
when a stop event is reported for hitting a catchpoint, GDB will now
report a BreakpointEvent with the attached breakpoint being of type
BP_CATCHPOINT - previously GDB would report a generic StopEvent in
this situation.
gdb/ChangeLog:
* NEWS: Mention Python BP_CATCHPOINT feature.
* python/py-breakpoint.c (pybp_codes): Add bp_catchpoint support.
(bppy_init): Likewise.
(gdbpy_breakpoint_created): Likewise.
gdb/doc/ChangeLog:
* python.texinfo (Breakpoints In Python): Add BP_CATCHPOINT
description.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.c (do_throw): New function.
(main): Call do_throw.
* gdb.python/py-breakpoint.exp (test_catchpoints): New proc.
|
|
This commit adds initial support for catchpoints to the guile
breakpoint API.
This commit adds a BP_CATCHPOINT constant which corresponds to
GDB's internal bp_catchpoint. The new constant is documented in the
manual.
The user can't create breakpoints with type BP_CATCHPOINT after this
commit, but breakpoints that already exist, obtained with
the (breakpoints) function, can now have this type.
gdb/ChangeLog:
* guile/scm-breakpoint.c (bpscm_type_to_string): Handle
bp_catchpoint.
(bpscm_want_scm_wrapper_p): Likewise.
(gdbscm_make_breakpoint): Likewise.
(breakpoint_integer_constants): Likewise.
gdb/doc/ChangeLog:
* guile.texinfo (Breakpoints In Guile): Add BP_CATCHPOINT
description.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_catchpoints): New proc.
|
|
When creating a breakpoint using the guile API, if an invalid
breakpoint type number was used then the error would report the wrong
argument position, like this:
(gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type 999))
ERROR: In procedure make-breakpoint:
ERROR: In procedure gdbscm_make_breakpoint: Out of range: invalid breakpoint type in position 3: 999
Error while executing Scheme code.
(gdb)
The 'position 3' here is actually pointing at WP_WRITE, when it should
say 'position 5' and point to the 999. This commit fixes this.
However, you also get errors like this:
(gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type BP_NONE))
ERROR: In procedure make-breakpoint:
ERROR: In procedure gdbscm_make_breakpoint: Out of range: invalid breakpoint type in position 3: 0
Error while executing Scheme code.
The BP_NONE is a valid breakpoint type, it's just not valid for
creating breakpoints through the 'make-breakpoint' API. The use of
'0' in the error message (which is the value of BP_NONE) is not
great. This commit changes the error in this case to:
(gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type BP_NONE))
ERROR: In procedure make-breakpoint:
ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in position 5: "BP_NONE"
Error while executing Scheme code.
Which seems better; we now use the name of the type, and report that
this type is unsupported.
gdb/ChangeLog:
* guile/scm-breakpoint.c (gdbscm_make_breakpoint): Split the error
for invalid breakpoint numbers, and unsupported breakpoint
numbers.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_watchpoints): Add new tests.
|
|
This patch adds a file with the ISA 3.1 check. The ISA 3.1 check is
added to the test to ensure the test is only run on ISA 3.1 or newer.
gdb/testsuite/ChangeLog
2021-06-25 Carl Love <cel@us.ibm.com>
* gdb.arch/powerpc-plxv-norel.exp: Add call to skip_power_isa_3_1_tests.
* lib/gdb.exp(skip_power_isa_3_1_tests): New gdb_caching_proc test.
|
|
While working on the DWARF psymtab replacement, I needed
addrmap_foreach to accept a gdb::function_view. This seemed like a
worthwhile change on its own, so I've written it separately for
submission.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/index-write.c (struct addrmap_index_data): Add
initializers.
<operator()>: Declare.
(addrmap_index_data::operator()): Rename from
add_address_entry_worker. Remove 'datap' parameter.
(write_address_map): Update.
* psymtab.c (struct dump_psymtab_addrmap_data): Remove
(dump_psymtab_addrmap_1): Remove 'data' parameter, add other
parameters.
(dump_psymtab_addrmap): Update.
* addrmap.c (struct addrmap_funcs) <foreach>: Remove 'data'
parameter.
(addrmap_foreach, addrmap_fixed_foreach): Likewise.
(struct mutable_foreach_data): Remove.
(addrmap_mutable_foreach_worker): Update.
(addrmap_mutable_foreach): Remove 'data' parameter.
* addrmap.h (addrmap_foreach_fn): Use gdb::function_view.
(addrmap_foreach): Remove 'data' parameter.
|
|
GNAT emits encoded type names, but these aren't usually of interest to
users. The Ada language code in gdb hides this oddity -- but the
Python layer does not. This patch changes the Python code to use the
decoded Ada type name, when appropriate.
I looked at decoding Ada type names during construction, as that would
be cleaner. However, the Ada support in gdb relies on the encodings
at various points, so this isn't really doable right now.
2021-06-25 Tom Tromey <tromey@adacore.com>
* python/py-type.c (typy_get_name): Decode an Ada type name.
gdb/testsuite/ChangeLog
2021-06-25 Tom Tromey <tromey@adacore.com>
* gdb.ada/py_range.exp: Add type name test cases.
|
|
When ada_decode encounters a name that it cannot decode, it simply
wraps it in <...>, which is used elsewhere in the Ada code to indicate
that a verbatim match should be done.
A subequent patch needed the ability to suppress this wrapping, so
this patch adds a new mode to ada_decode.
2021-06-25 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_decode): Add wrap parameter.
* ada-lang.h (ada_decode): Add wrap parameter.
|
|
At the moment, the core target has its own gdbarch (m_core_gdbarch), and that
gets set from the core_bfd on the core target's constructor.
That gdbarch doesn't contain a target description because it is constructed
before we get a chance to fetch the target description.
As a result, some hooks that depend on the target description being set are
not set, and that leads to problems. One of the examples is
gdbarch_report_signal_info, which is used to show AArch64 tag violation
information.
Fix this by reading the target description before fetching the core file's
gdbarch.
gdb/ChangeLog:
2021-06-25 Luis Machado <luis.machado@linaro.org>
* corelow.c (core_target::core_target) Update to read target
description.
|
|
Add a stub prototype for the dump function meant to be called by devs
from gdb, and trim unused functions that aren't supposed to be used.
|
|
The Linux syscall interface, depending on architecture, handles up to
7 arguments. Extend the callback API to handle those.
|
|
|
|
When running test-case gdb.base/info-macros.exp, I run into:
...
PASS: gdb.base/info-macros.exp: info macro --
PASS: gdb.base/info-macros.exp: info macro --
DUPLICATE: gdb.base/info-macros.exp: info macro --
PASS: gdb.base/info-macros.exp: info macro --
...
These messages come from gdb_test calls using the following commands:
- "info macro --"
- "info macro -- "
- "info macro -- ".
Apparantly the test names get stripped of trailing whitespace, and the first
two end up identical.
Fix this by explicitly specifying an <EOL> after the trailing whitespace in
the test name, such that we have:
...
PASS: gdb.base/info-macros.exp: info macro --
PASS: gdb.base/info-macros.exp: info macro -- <EOL>
PASS: gdb.base/info-macros.exp: info macro -- <EOL>
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-24 Tom de Vries <tdevries@suse.de>
* gdb.base/info-macros.exp: Add <EOL> after trailing whitespace in
test names.
|
|
I found the following duplicates in gdb.base/argv0-symlink.exp:
...
DUPLICATE: gdb.base/argv0-symlink.exp: set print repeats 10000
DUPLICATE: gdb.base/argv0-symlink.exp: set print elements 10000
...
Fix these by using with_test_prefix "file symlink" / "dir symlink".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-24 Tom de Vries <tdevries@suse.de>
* gdb.base/argv0-symlink.exp: Use with_test_prefix.
|
|
Power10 prefixed instructions must not cross 64-byte boundaries.
This is already handled.
However, on XCOFF, the csect must be updated to match the new
alignment.
* config/tc-ppc.c (md_assemble): Update ppc_current_csect
alignment when finding prefixed instructions.
|
|
If code tries to send a signal to itself, the callback layer ignores
it and forces the caller to handle it. This allows the sim to turn
that into an engine halt rather than actually killing the sim.
|
|
The cris linux syscall layers assume getpid returns a constant,
so add a custom function to provide that.
|
|
This will make it easier to emulate the syscall. If the kill target
is the sim itself, don't do anything. This forces the higher layers
to make a decision as to how to handle this event: like halting the
overall engine process.
|
|
|
|
We rewrite srcdir in subdir Makefiles that we generate from the common
parent dir since it points to the parent dir. Since @srcdir@ can be a
variety of formats (relative & absolute), switch to @abs_srcdir@ which
is a lot easier to adjust. Our use of srcdir in here should handle it.
|
