After enabling location description to be on a DWARF stack, it is now
needed to check the frame context information validity when creating a
register location description.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::execute_stack_op): Add
check_frame_info call for DW_OP_reg operations.
read_addr_from_reg function is now only called from frame.c file, this
means that the function can safely be moved there.
gdb/ChangeLog:
* dwarf2/expr.c (read_addr_from_reg): Move function to frame.c.
* dwarf2/expr.h (read_addr_from_reg): Remove function.
* dwarf2/frame.c (read_addr_from_reg): Add function from
expr.c.
After the switch to the new evaluator implementation, it is now
possible to completely remove the dwarf_expr_context class from the
expr.h interface and encapsulate it inside the expr.c file.
The new interface consists of a new function called dwarf2_evaluate
that takes a DWARF expression stream, initial DWARF stack elements (in
a form of a vector of a struct value objects), evaluation context and
expected result type information. Function returns an evaluation result
in a form of a struct value object.
Currently, there is ever only one initial stack element provided to the
evaluator and that element is always a memory address, so having a
vector of struct value object might seems like an overkill.
In reality this new flexibility allows implementation of a new DWARF
attribute extensions that could provide any number of initial stack
elements to describe any location description or value.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf2_evaluate): New function.
(struct dwarf_expr_context): Move from expr.h.
(class dwarf_entry): Move from expr.h
(dwarf_expr_context::push_address): Remove function.
* dwarf2/expr.h (struct dwarf_expr_context): Move to expr.c.
(class dwarf_entry): Move to expr.c.
(address_type): Expose function.
* dwarf2/frame.c (execute_stack_op): Now calls dwarf2_evaluate.
* dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Now calls
dwarf2_evaluate.
(dwarf2_locexpr_baton_eval): Now calls dwarf2_evaluate.
This is just a cosmetic cleanup of the expr.h and expr.c documentation.
gdb/ChangeLog:
* dwarf2/expr.c: Comments cleanup.
* dwarf2/expr.h: Comments cleanup.
To replace existing DWARF stack element (dwarf_stack_value) with
dwarf_entry class based objects, a support for conversion between
struct value and the new classes is needed. The reason for this is
that dwarf_entry based classes are not designed to be visible outside
the expr.c file. This makes the DWARF expression evaluator more self
contained. This can be beneficial if there is ever a need to have a
DWARF support in gdbserver.
In the previous patch the conversion between the DWARF entry classes to
the struct value has been already added in a form of a to_gdb_value
method.
The interface that is still missing is to convert from struct value to
the DWARF entry classes. New static function gdb_value_to_dwarf_entry
has been added for this purpose.
We also need a way to perform DWARF arithmetic and logical operations
on DWARF values and for this a new set of static functions
(dwarf_value_X) has been provided.
Currently the existing struct value operations are used under the
hood of these functions to avoid the code duplication. Vector types
are planned to be promoted to base types in the future anyway which
means that the operations subset needed is just going to grow.
Also, dwarf_entry class declaration had to be temporarily moved to the
expr.h file so that unique_ptr wrapper type could be used in some
dwarf_expr_context method declaration and will be moved back to the
expr.c file in one of the next patches.
Now, everything is ready so that the DWARF stack element can easily be
swapped out.
It is worth mentioning that a few tests under gdb/testsuite/gdb.dwarf2/
folder, also had to be changed to reflect the design change which
effected an edge case error message text. Tests that had to be changed
slightly are: dw2-param-error.exp, dw2-stack-boundary.exp and
dw2_op_call.exp. The reason for this is that they all contained a
DWARF expression that once evaluated resulted in a stack underflow
error reported by a fetch method, but with the switch to the new stack
element type and a bit different stack algorithm, the message can no
longer be reported by that method, but by a stack pop method instead.
gdb/ChangeLog:
* dwarf2/expr.c (gdb_value_to_dwarf_entry): New function.
(to_location): New function.
(to_value): New function.
(dwarf_value_cast_op): New function.
(dwarf_value_complement_op): New function.
(dwarf_value_negation_op): New function.
(dwarf_value_binary_op): New function.
(dwarf_value_less_op): New function.
(dwarf_value_equal_op): New function.
(allocate_piece_closure): Remove unused function.
(dwarf_expr_context::push): Change to use dwarf_entry based
classes.
(dwarf_expr_context::push_address): Change to use dwarf_entry
based classes.
(dwarf_expr_context::fetch): Change to use dwarf_entry based
classes.
(dwarf_expr_context::read_mem): Remove method.
(dwarf_expr_context::fetch_result): Change to use dwarf_entry
based classes.
(dwarf_expr_context::fetch_address): Change to use dwarf_entry
based classes.
(dwarf_expr_context::fetch_in_stack_memory): Remove method.
(dwarf_expr_context::add_piece): Change to use dwarf_entry based
classes.
(dwarf_expr_context::execute_stack_op): Change to use dwarf_entry
based classes.
(dwarf_location::clone): New method.
(dwarf_value::clone): New method.
* dwarf2/expr.h (class dwarf_entry): New declaration.
(struct dwarf_stack_value): Remove structure.
(struct dwarf_expr_context): Change to use dwarf_entry based.
(dwarf_entry::clone): New method.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-param-error.exp: Error message text change.
* gdb.dwarf2/dw2-stack-boundry.exp: Error message text change.
* gdb.dwarf2/dw2-op-call.exp Error message text change.
The result of the DWARF expression evaluation is expected to be in a
format of a struct value object. This means that a new to_gdb_value
method is needed for both dwarf_location and dwarf_value classes.
In the case of the dwarf_value class, the conversion between that
class and struct value can happen often, this is why it is usefull to
cache once created struct value object in a dwarf_value
m_gdb_value member to reduce the number of conversions needed.
However, this also means that the to_gdb_value method cant be declared
as a constant method.
In the case of classes that derive from dwarf_location class, there is
now a need for a cloning method because the encapsulating
computed_closure class has a life span separated from the expression
evaluator.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_entry::to_gdb_value): New method.
(dwarf_location::to_gdb_value): New method.
(dwarf_location::clone_location): New method.
(dwarf_value::m_gdb_value): New member.
(dwarf_value::to_gdb_value): New method.
(dwarf_undefined::to_gdb_value): New method.
(dwarf_undefined::clone_location): New method.
(dwarf_memory::to_gdb_value): New method.
(dwarf_memory::clone_location): New method.
(dwarf_register::to_gdb_value): New method.
(dwarf_register::clone_location): New method.
(dwarf_implicit::to_gdb_value): New method.
(dwarf_implicit::clone_location): New method.
(dwarf_implicit_pointer::to_gdb_value): New method.
(dwarf_implicit_pointer::clone_location): New method.
(dwarf_composite::to_gdb_value): New method.
(dwarf_composite::clone_location): New method.
At this point all support is there to add a new callback interface
for the computed struct value infrastructure.
Original callback interface (piece closure) is going to be removed as
soon as the switch to the new DWARF entry classes is done in the next
few patches.
gdb/ChangeLog:
* dwarf2/expr.c (class computed_closure): New class.
(closure_value_funcs): New closure callback structure.
(copy_value_closure): New function.
(free_value_closure): New function.
(rw_closure_value): New function.
(check_synthetic_pointer): New function.
(write_closure_value): New function.
(read_closure_value): New function.
(is_optimized_out_closure_value): New function.
(indirect_closure_value): New function.
(coerce_closure_ref): New function.
Similarly to the is_implicit_ptr_at method, the existing function
callback interface of the computed struct value, requiers a way to
check if the underlying location description describes any part as
optimized out.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::is_optimized_out):
New method.
(dwarf_implicit::is_optimized_out): New method.
(dwarf_register::is_optimized_out): New method.
(dwarf_composite::is_optimized_out): New method.
Similarly to the is_implicit_ptr_at method, the existing function
callback interface of the computed struct value, requiers a way to
apply indirection to an implicit pointer on a given offset of a given
length of an underlying location description.
This is different than reading from a struct value object (previously
described write_to_gdb_value method) in a way that the result of this
operation is expected to be a struct value of a pointed source level
variable instead of reading the value of that variable.
In the same way this is also different operation than the deref method
because the deref returns a read value of a given type from that
location description.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::indirect_implicit_ptr):
New method.
(dwarf_implicit_pointer::indirect_implicit_ptr): New method.
(dwarf_composite::indirect_implicit_ptr): New method.
Another expectation of the existing function callback interface of the
computed struct value is to check if a specific part (on a given offset
of a given length) of an underlying location description is an implicit
pointer location description.
To satisfy this expectation a new is_implicit_ptr_at has been added.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::is_implicit_ptr_at):
New method.
(dwarf_implicit_pointer::is_implicit_ptr_at): New method.
(dwarf_composite::is_implicit_ptr_at): New method.
Similar story behind the previous read_from_gdb_value method applies
to the new write_to_gdb_value.
In the same way, reading the data from a location described and writing
that data to a struct value object, can be different from just generic
read the data from a buffer (location description read method).
To make this distinction clear, a new write_to_gdb_value method is
added to classes that derive from location description class.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::write_to_gdb_value):
New method.
(dwarf_composite::write_to_gdb_value): New method.
The few patches are addressing the expectations of the existing
function calback interface of the computed struct value objects.
As mentioned in the previous patches the location description and the
interaction with that location are opaque to the struct value object,
but currently that interaction is influenced by the data contained
inside of that object and outside of the location description class.
Also, the struct value evaluation involves more then just writing or
reading the object contents buffer, in certain cases it is also
expected to throw an exception or mark different parts of the object
with additional information (optimized out bitmap for example).
As a result, reading the data from a struct value object and writing
that data into the location described, can be different then just
generic writing the data from a buffer (dwarf_location write method).
To make this distinction clear a new read_from_gdb_value method is
added to classes that derive from location description class.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::read_from_gdb_value):
New method.
(dwarf_composite::read_from_gdb_value): New method.
Concept of reading from a location seems to be too low level for the
DWARF standard. What the standard actually describes is a concept of
dereferencing, where the type of the operation result can be
specified in advance.
This can be seen in the definition of the DW_OP_derefX family of
expression operations, but it is also happening implicitly in the case
of DW_OP_fbreg, DW_OP_regval_type and DW_OP_bregX family of operations.
Currently, the DW_OP_derefX operations will take the value from the
DWARF expression stack and implicitly convert it to a memory location
description (in reality treat it as a memory address for a given
target) and apply the dereference operation to it. When we allow any
location description on a DWARF expression stack, these operations need
to work in the same way.
The conclusion here is that we need a universal method that models the
dereference operation for any class derived from a location description
class.
It is worth mentioning that because of how the passed in buffers are
currently being implemented, we needed a specialisation for the deref
method of the dwarf_memory class to support them.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::deref): New method.
(dwarf_memory::deref): New method.
After adding the interface for reading from the location, it also
makes sense to add the interface for writing.
To be clear, DWARF standard doesn't have a concept of writting to a
location, but because of the way how callback functions are used to
interact with the opaque implementation of the computed struct value
objects, the choice was to either use the existing DWARF entry classes
or to invent another way of representing the complexity behind those
computed objects.
Adding a write method seems to be a simpler option of the two.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::write): New method.
(dwarf_undefined::write): New method.
(dwarf_memory::write): New method.
(dwarf_register::write): New method.
(dwarf_implicit::write): New method.
(dwarf_implicit_pointer::write): New method.
(dwarf_composite::write): New method.
After adding the interface for register and memory location access, a
new method for reading from any location derived from a dwarf_location
class, can now be defined.
In the case of implicit pointer location description the existing
indirect_synthetic_pointer interface requiers a type of the pointer
to be specified, so for a generic read interface the only type that
makes sense is the DWARF generic type. This means that the existing
address_type method of a dwarf_expr_context class needs to be exposed
outside of that class.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::read): New method.
(dwarf_undefined::read): New method.
(dwarf_memory::read): New method.
(dwarf_register::read): New method.
(dwarf_implicit::read): New method.
(dwarf_implicit_pointer::read): New method.
(dwarf_composite::read): New method.
(dwarf_expr_context::address_type): Change to use the new
address_type function.
(address_type): New function.
Following the idea from the last patch this patch is adding a
conversion method from any dwarf_location derived object into
a dwarf_value object.
Currently, we only know how to convert from a memory location
description into a value, but it is resonable to expect a set
of target hooks that would let the target decide on how to do
other conversions in the future.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_location::to_value): New method.
(dwarf_memory::to_value): New method.
(ill_formed_expression): New function.
DWARF standard already contains an implicit conversion between location
description and a DWARF value. In the DWARF 5 version, one place
where this can happen is at the very end of the evaluation where a
client decides if the result is expected to be in a form of a value or
a location description (as_lval argument of the new evaluation method).
By allowing any location description to be on the DWARF stack, these
implicit conversions are expected on per operation basis which means
that the new dwarf_value class need to have a support for it.
This patch adds a conversion method from a dwarf_value object into a
location description object.
To support the conversion method we also need an implementation of the
C++14 standard library function make_unique which was copied from the
standard library implementation.
gdb/ChangeLog:
* dwarf2/expr.c (class dwarf_value::to_location): New method.
gdbsupport/ChangeLog:
* common-utils.h (make_unique): New function.
The rest of the patch series addresses the issues described in a
"Motivation" section of the AMD's DWARF standard extensions that
can be found at:
https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
The document describes a couple of main issues found when using the
current DWARF 5 version to describe optimized code for SIMD and SIMT
architectures.
Without going much into details described in the document, the main
point is that DWARF version 5 does not allow a proper support for
address spaces and it does not allow a location description to be used
anywhere in the DWARF expression, instead a location description can
using a result left on the DWARF stack (after the evaluation of that
expression) to describe the location.
Both issues can be solved in a clean way by introducing a new set of
classes that describe all entry types which can be placed on a DWARF
stack, while keeping most of backward compatibility with the previous
standard version. These entry types can now be either a typed value
or any location description.
Known edge case where placing a location description on the DWARF stack
is not fully backward compatible with DWARF version 5 is in the case of
DW_OP_call operations, where the current standard only defines that an
expression stack is shared between the caller and the callee, but there
it is unknown what happens with the resuling location description after
the evaluation of the callee's location description expression.
Considering that this edge case is not defined in the standard, it
would be very unusual and dangerous for any compiler to use it in their
own way and in the existing testsuite, there is no indication of that.
Currently, the result of an expression evaluation is kept in a separate
data structure, while with the new approach, it will be always found as
a top element of the DWARF stack.
Question here is, why do we need a new set of classes and why not just
use the struct value instead?
As it stands, there are couple of issues with using the struct value to
describe a DWARF stack element:
- It is not designed to represent a DWARF location description
specifically, instead it behaves more like unified debug information
format that represents an actual target resource. One example of this
is accessing data of a struct value register location description,
where if the amount of data accessed is larger then the register,
results in accessing more then one register. In DWARF this is not a
valid behavior and locations that span more then one register should be
described as a composite location description.
- There is a tight coupling between struct value and it's type
information, regardless if the data represented is describing a value
(not_lval) or a location description. While the type information
dictates how the data is accessed for a struct value case, in DWARF,
location description doesn't have a type so data access is not bound by
it.
- DWARF values only support much simpler base types, while struct value
can be linked to any type. Admittedly, new classes are still using the
same struct value infrastructure for a value based operations at the
moment, but that is planned to change in the near future.
- struct value register location description requires a frame id
information which makes them unsuitable for CFA expression evaluation.
So, there seems to be a lack of separation of concerns in the design
of a struct value infrastructure, while the new classes are handling
one specific purpose and are completely encapsulated in the expr.c.
Additional benefit of this design is that it makes a step in a
right direction for being able to evaluate DWARF expressions on a
gdbserver side in the near future, which sounds like a desirable thing.
It is also worth mentioning that this new location description
representation is based on a bit granularity (the bit_suboffset class
member) even though the DWARF standard has a very limited support for
it (mostly used for DW_OP_bit_piece operation).
By allowing any location description to define a bit sub-offset of the
location, we are able to give more options for supporting of new
concepts (like the existing packed arrays in Ada language).
In this patch, a new set of classes that describe a DWARF stack element
are added. The new classes are:
- Value - describes a numerical value with a DWARF base type.
- Location description - describes a DWARF location description.
- Undefined location - describes a location that is not defined.
- Memory location - describes a location in memory.
- Register location - describes a register location in a frame
context.
- Implicit location - describes a location that implicitly holds a
value that it describes.
- Implicit pointer - describes a concept of an implicit pointer to
a source variable.
- Composite location - describes a location that is composed from
pieces of other location descriptions.
For now, these classes are just defined, and they are planned to be
used by the following patches.
gdb/ChangeLog:
* dwarf2/expr.c (class dwarf_entry): New class.
(class dwarf_value): New class.
(class dwarf_location): New class.
(class dwarf_undefined): New class.
(class dwarf_memory): New class.
(class dwarf_register): New class.
(class dwarf_implicit): New class.
(class dwarf_implicit_pointer): New class.
(class dwarf_composite): New class.
* value.c (pack_unsigned_long): Expose function.
* value.h (pack_unsigned_long): Expose function.
DWARF expression evaluator is currently using a few different
interfaces for memory access: write_memory_with_notification,
read_value_memory, read_memory.
They all seem incosistent, while some of them even need a struct
value typed argument to be present.
This patch is simplifying that interface by replacing it with two new
low level functions: read_from_memory and write_to_memory.
The advantage of this new interface is that it behaves in the same way
as the register access interface from the previous patch. Both of these
have the same error returning policy, which will be usefull for the
following patches.
* dwarf2/expr.c (xfer_memory): New function.
(read_from_memory): New function.
(write_to_memory): New function.
(rw_pieced_value): Now calls the read_from_memory and
write_to_memory functions.
DWARF expression evaluator is currently using get_frame_register_bytes
and put_frame_register_bytes interface for register access.
The problem with evaluator using this interface is that it allows a
bleed out register access. This means that if the caller specifies a
larger amount of data then the size of a specified register, the
operation will continue accessing the neighboring registers until a
full amount of data has been reached.
DWARF specification does not define this behavior, so a new simplified
register access interface is needed instead.
* dwarf2/expr.c (read_from_register): New function.
(write_to_register): New function.
(rw_pieced_value): Now calls the read_from_register and
write_to_register functions.
Investigating the PR28530 testcase, which has a fuzzed compression
header with an enormous size, I noticed that decompress_contents is
broken when the size doesn't fit in strm.avail_out. It wouldn't be
too hard to support larger sizes (patches welcome!) but for now just
stop decompress_contents from returning rubbish.
PR 28530
* compress.c (decompress_contents): Fail when uncompressed_size
is too big.
(bfd_init_section_decompress_status): Likewise.
The "set index-cache" command is used at the same time as a prefix
command (prefix for "set index-cache directory", for example), and a
boolean setting for turning the index-cache on and off. Even though I
did introduce that, I now don't think it's a good idea to do something
non-standard like this.
First, there's no dedicated CLI command to show whether the index-cache
is enabled, so it has to be custom output in the "show index-cache
handler". Also, it means there's no good way a MI frontend can find out
if the index-cache is enabled. "-gdb-show index-cache" doesn't show it
in the MI output record:
(gdb) interpreter-exec mi "-gdb-show index-cache"
~"\n"
~"The index cache is currently disabled.\n"
^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}}
Fix this by introducing "set/show index-cache enabled on/off", regular
boolean setting commands. Keep commands "set index-cache on" and "set
index-cache off" as deprecated aliases of "set index-cache enabled",
with respectively the default arguments "on" and "off".
Update tests using "set index-cache on/off" to use the new command.
Update the regexps in gdb.base/maint.exp to figure out whether the
index-cache is enabled or not. Update the doc to mention the new
commands.
Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3
The getter and setter in struct setting always receive and return values
by const reference. This is not necessary for scalar values (like bool
and int), but more importantly it makes it a bit annoying to write a
getter, you have to use a scratch static variable or something similar
that you can refer to:
const bool &
my_getter ()
{
static bool value;
value = function_returning_bool ();
return value;
}
Change the getter and setter function signatures to receive and return
value by value instead of by reference, when the underlying data type is
scalar. This means that string-based settings will still use
references, but all others will be by value. The getter above would
then be re-written as:
bool
my_getter ()
{
return function_returning_bool ();
}
This is useful for a patch later in this series that defines a boolean
setting with a getter and a setter.
Change-Id: Ieca3a2419fcdb75a6f75948b2c920b548a0af0fd
The class_deprecated enumerator isn't assigned anywhere, so remove it.
Commands that are deprecated have cmd_list_element::cmd_deprecated set
instead.
Change-Id: Ib35e540915c52aa65f13bfe9b8e4e22e6007903c
Remove two unnecessary nullptr checks. If aliases is nullptr, then the
for loops will simply be skipped.
Change-Id: I9132063bb17798391f8d019af305383fa8e0229f
I get some diffs when running autoconf in gdbserver, probably leftovers
from commit 5dfe4bfcb9 ("Fix format_pieces selftest on Windows").
Re-generate configure in that directory.
Change-Id: Icdc9906af95fbaf1047a579914b2983f8ec5db08
Always check sections with the corrupt size for non-MMO files. Skip MMO
files for compress_status == COMPRESS_SECTION_NONE since MMO has special
handling for COMPRESS_SECTION_NONE.
PR binutils/28530
* compress.c (bfd_get_full_section_contents): Always check
sections with the corrupt size.
Add/Remove the rvc extension to/from the riscv_subsets once the
.option rvc/norvc is set. So that we don't need to always check
the riscv_opts.rvc in the riscv_subset_supports, just call the
riscv_lookup_subset to search the subset list is enough.
Besides, we will need to dump the instructions according to the
elf architecture attributes. That means the dis-assembler needs
to parse the architecture string from the elf attribute before
dumping any instructions, and also needs to recognized the
INSN_CLASS* classes from riscv_opcodes. Therefore, I suppose
some functions will need to be moved from gas/config/tc-riscv.c
to bfd/elfxx-riscv.c, including riscv_multi_subset_supports and
riscv_subset_supports. This is one of the reasons why we need
this patch.
This patch passes the gcc/binutils regressions of rv32emc-elf,
rv32i-elf, rv64gc-elf and rv64gc-linux toolchains.
bfd/
* elfxx-riscv.c (riscv_remove_subset): Remove the extension
from the subset list.
(riscv_update_subset): Add/Remove an extension to/from the
subset list. This is used for the .option rvc or norvc.
* elfxx-riscv.h: Added the extern bool riscv_update_subset.
gas/
* config/tc-riscv.c (riscv_set_options): Removed the unused
rve flag.
(riscv_opts): Likewise.
(riscv_set_rve): Removed.
(riscv_subset_supports): Removed the riscv_opts.rvc check.
(riscv_set_arch): Don't need to call riscv_set_rve.
(reg_lookup_internal): Call riscv_subset_supports to check
whether the rve is supported.
(s_riscv_option): Add/Remove the rvc extension to/from the
subset list once the .option rvc/norvc is set.
The multi-run logic for mips involves a bit of codegen and rewriting
of files to include per-architecture prefixes. That can result in
files with missing prototypes which cause compiler errors. In the
case of mips-sde-elf targets, we have:
$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
sim_engine_run -> m16mips64r2_engine_run
$srcdir/micromipsrun.c -> micromipsmicromips_run.c
sim_engine_run -> micromips64micromips_engine_run
micromipsmicromips_run.c:80:1: error: no previous prototype for 'micromips64micromips_engine_run' [-Werror=missing-prototypes]
80 | micromips64micromips_engine_run (SIM_DESC sd, int next_cpu_nr, int nr_cpus,
We generate headers for those prototypes in the configure script,
but only include them in the generated multi-run.c file. Update the
rewrite logic to turn the sim-engine.h include into the relevant
generated engine include so these files also have their prototypes.
$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
sim-engine.h -> m16mips64r2_engine.h
$srcdir/micromipsrun.c -> micromipsmicromips_run.c
sim-engine.h -> micromips64micromips_engine.h
We don't need to build this anymore ourselves since the common build
includes it and produces the same object code. We also need to pull
in the split constant modules after the refactoring and pulling them
out of nltvals.def & targ-map.o. This doesn't matter for the sim
directly, but does for gdb and other users of libsim.
We also delete some conditional source tree logic since we already
require this be the "new" combined tree with a ../common/ dir. This
has been the case for decades at this point.
When building gnu-nat.c, we get:
CXX gnu-nat.o
gnu-nat.c: In member function 'virtual void gnu_nat_target::create_inferior(const char*, const string&, char**, int)':
gnu-nat.c:2117:13: error: 'struct inf' has no member named 'target_is_pushed'
2117 | if (!inf->target_is_pushed (this))
| ^~~~~~~~~~~~~~~~
gnu-nat.c:2118:10: error: 'struct inf' has no member named 'push_target'
2118 | inf->push_target (this);
| ^~~~~~~~~~~
This is because of a confusion between the generic `struct inferior`
variable and the gnu-nat-specific `struct inf` variable. Fix by
referring to `inferior`, not `inf`.
Adjust the comment on top of `struct inf` to clarify the purpose of that
type.
Co-Authored-By: Andrea Monaco <andrea.monaco@autistici.org>
Change-Id: I2fe2f7f6ef61a38d79860fd262b08835c963fc77
We see some additional failures when running the testsuite against a GDB
compiled with ASan, compared to a GDB compiled without ASan. Some of
them are caused by the memory leak report shown by the GDB process when
it exits, and the fact that it makes it exit with a non-zero exit code.
I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my
environment when running the tests, but I don't always do it. I think
it would be nice if the testsuite did it. I don't see any use to have
leak detection when running the tests. That is, unless we ever have a
test that ensures GDB doesn't leak memory, which isn't going to happen
any time soon.
Here are some tests I found that were affected by this:
gdb.base/batch-exit-status.exp
gdb.base/many-headers.exp
gdb.base/quit.exp
gdb.base/with-mf.exp
gdb.dwarf2/gdb-add-index.exp
gdb.dwarf2/gdb-add-index-symlink.exp
gdb.dwarf2/imported-unit-runto-main.exp
Change-Id: I784c7df8a13979eb96587f735c1d33ba2cc6e0ca
While looking at an apparently malformed executable with
"readelf --debug-dump=loc", I got this warning:
readelf: ./main: Warning: There is a hole [0x89 - 0x95] in .debug_loc section.
However, the executable only has a .debug_loclists section.
This patch fixes the warning messages in display_debug_loc to use the
name of the section that is being processed.
binutils/ChangeLog
2021-11-03 Tom Tromey <tromey@adacore.com>
* dwarf.c (display_debug_loc): Use section name in warnings.
The current register set selection mechanism for AArch64 is static, based
on a pre-populated array of register sets.
This means that we might potentially probe register sets that are not
available. This is OK if the kernel errors out during ptrace, but probing the
tag_ctl register, for example, does not result in a ptrace error if the kernel
supports the tagged address ABI but not MTE (PR 28355).
Making the register set selection dynamic, based on feature checks, solves
this and simplifies the code a bit. It allows us to list all of the register
sets only once, and pick and choose based on HWCAP/HWCAP2 or other properties.
I plan to backport this fix to GDB 11 as well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28355
Currently for a binary compiled normally (without -fsanitize=address) but with
LD_PRELOAD of ASAN one gets:
$ ASAN_OPTIONS=detect_leaks=0:alloc_dealloc_mismatch=1:abort_on_error=1:fast_unwind_on_malloc=0 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb
=================================================================
==1909567==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete []) on 0x602000001570
#0 0x7f1c98e5efa7 in operator delete[](void*) (/usr/lib64/libasan.so.6+0xb0fa7)
...
0x602000001570 is located 0 bytes inside of 2-byte region [0x602000001570,0x602000001572)
allocated by thread T0 here:
#0 0x7f1c98e5cd1f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaed1f)
#1 0x557ee4a42e81 in operator new(unsigned long) (/usr/libexec/gdb+0x74ce81)
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/usr/lib64/libasan.so.6+0xb0fa7) in operator delete[](void*)
==1909567==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
==1909567==ABORTING
Despite the code called properly operator new[] and operator delete[].
But GDB's new-op.cc provides its own operator new[] which gets translated into
malloc() (which gets recogized as operatore new(size_t)) but as it does not
translate also operators delete[] Address Sanitizer gets confused.
The question is how many variants of the delete operator need to be provided.
There could be 14 operators new but there are only 4, GDB uses 3 of them.
There could be 16 operators delete but there are only 6, GDB uses 2 of them.
It depends on libraries and compiler which of the operators will get used.
Currently being used:
U operator new[](unsigned long)
U operator new(unsigned long)
U operator new(unsigned long, std::nothrow_t const&)
U operator delete[](void*)
U operator delete(void*, unsigned long)
Tested on x86_64-linux.
yyleng gives the pattern length, xstrdup just copies up to the NUL.
So it is quite possible writing at an index of yyleng-2 overflows
the xstrdup allocated string buffer. xmemdup quite handily avoids
this problem, even writing the terminating NUL over the trailing
quote. Use it in ldlex.l too where we'd already had a report of this
problem and fixed it by hand, and to implement xmemdup0 in gas.
binutils/
* deflex.l (single and double quote strings): Use xmemdup.
gas/
* as.h (xmemdup0): Use xmemdup.
ld/
PR 20906
* ldlex.l (double quote string): Use xmemdup.
These are marked inline, so building w/gcc at higher optimization
levels will automatically discard them. But building with -O0 will
trigger unused function warnings, so fix that.
The common before/after cover functions in the common mloop generator
are not used by all architecture ports. Doesn't seem to be a hard
requirement, so marking them optional (i.e. unused) is fine.
The cris execute function is conditionally used depending on the
fast-build mode settings, so mark it unused too.
That assert would be more obvious if it were reported as
"addr_ranges <= end_ranges". Fix that by using the obvious variable
in the final loop. Stop the assertion by using a signed comparison:
It's possible for the rounding up of the arange pointer to exceed the
end of the block when the block size is fuzzed.
* dwarf.c (display_debug_aranges): Use "end_ranges" in loop
displaying ranges rather that "start". Simplify rounding up
to 2*address_size boundary. Use signed comparison in loop.
These rules don't depend on the target compiler settings, so hoist
the build logic up to the common builds for better parallelization.
We have to extend the genmloop.sh logic a bit to allow outputting
to a subdir since it always assumed cwd was the right place.
We leave the cgen maintainer rules in the subdirs for now as they
aren't normally run, and they rely on cgen logic that has not yet
been generalized.
These rules don't depend on the target compiler settings, so hoist
the build logic up to the common builds for better parallelization.
We leave the mips rules in place as they depend on complicated
arch-specific configure logic that needs to be untangled first.
This file doesn't use anything from bfd (sysdep.h), so drop that
include. This avoids an implicit dependency on the generated
config.h which can be problematic for build-time tools.
Also swap stdio.h for stddef.h. This file isn't doing or using
any I/O structures, but it does need NULL.
This patch removes any fake (linker created) function descriptor
symbol if its code entry symbol isn't dynamic, to ensure bogus dynamic
symbols are not created. The change to func_desc_adjust requires that
it be run only once, which means ppc64_elf_tls_setup can't call it for
just a few selected symbols.
PR 28523
* elf64-ppc.c (func_desc_adjust): If a function entry sym is
not dynamic and has no plt entry, hide any associated fake
function descriptor symbol.
(ppc64_elf_edit): Move func_desc_adjust iteration over syms to..
(ppc64_elf_tls_setup): ..here.
