aarch64-tdep.c defines the following macro:
#define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \
do \
{ \
unsigned int mem_len = LENGTH; \
if (mem_len) \
{ \
MEMS = XNEWVEC (struct aarch64_mem_r, mem_len); \
memcpy(&MEMS->len, &RECORD_BUF[0], \
sizeof(struct aarch64_mem_r) * LENGTH); \
} \
} \
while (0)
This is simlpy allocating a new array and copying it. However, for
the destination address, it is actually copying into the first member
of the first element of the array (`&MEMS->len"). This elicits a
warning with GCC 12:
../../binutils-gdb/gdb/aarch64-tdep.c: In function ‘int aarch64_process_record(gdbarch*, regcache*, CORE_ADDR)’:
../../binutils-gdb/gdb/aarch64-tdep.c:3711:23: error: writing 16 bytes into a region of size 8 [-Werror=stringop-overflow=]
3711 | memcpy(&MEMS->len, &RECORD_BUF[0], \
| ^
../../binutils-gdb/gdb/aarch64-tdep.c:4394:3: note: in expansion of macro ‘MEM_ALLOC’
4394 | MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count,
| ^~~~~~~~~
../../binutils-gdb/gdb/aarch64-tdep.c:3721:12: note: destination object ‘aarch64_mem_r::len’ of size 8
3721 | uint64_t len; /* Record length. */
| ^~~
The simple fix is to reference the array, `MEMS' as the destination of the copy.
Tested by rebuilding.
# Please enter the commit message for your changes. Lines starting
# with '#' will be kept; you may remove them yourself if you want to.
# An empty message aborts the commit.
#
# Date: Tue Jan 25 08:28:32 2022 -0800
#
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
# (use "git push" to publish your local commits)
#
# Changes to be committed:
# modified: aarch64-tdep.c
#
This changes gdbarch dumping to use filtered output. This seems a bit
better to me, both on the principle that this is an ordinary command,
and because the output can be voluminous, so it may be nice to stop in
the middle.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
The process record code often emits unfiltered output. In some cases,
this output ought to go to gdb_stderr (but see below). In other
cases, the output is guarded by a logging variable and so ought to go
to gdb_stdlog. This patch makes these changes.
Note that in many cases, the output to stderr is followed by a
"return -1", which is how process record indicates an error. It seems
to me that calling error here would be preferable, because, in many
cases, that's all the caller does when it sees a -1. However, I
haven't made this change.
This is part of PR gdb/7233.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
Consider the following code:
type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
function Call_FP1 (F : FP1_Type) return FP1_Type is
begin
return F;
end Call_FP1;
When the default in GCC is to generate proper DWARF info for fixed point
types, then in gdb, printing the result of a call to call_fp1 with a
decimal parameter leads to:
(gdb) p call_fp1(0.5)
$1 = 0
The displayed value is wrong, and we actually expected:
(gdb) p call_fp1(0.5)
$1 = 0.5
What happened is that our fixed point type parameter got promoted to a
32bit integer because we detected that the length of that object was less
than 4 bytes. The compiler does not perform this promotion and therefore
GDB should not either.
This patch fixes the behavior described above.
I would like to be able to use non-trivial types in gdbarch_tdep types.
This is not possible at the moment (in theory), because of the one
definition rule.
To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and
make them inherit from a gdbarch_tdep base class. The inheritance is
necessary to be able to pass pointers to all these <arch>_gdbarch_tdep
objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep.
These objects are never deleted through a base class pointer, so I
didn't include a virtual destructor. In the future, if gdbarch objects
deletable, I could imagine that the gdbarch_tdep objects could become
owned by the gdbarch objects, and then it would become useful to have a
virtual destructor (so that the gdbarch object can delete the owned
gdbarch_tdep object). But that's not necessary right now.
It turns out that RISC-V already has a gdbarch_tdep that is
non-default-constructible, so that provides a good motivation for this
change.
Most changes are fairly straightforward, mostly needing to add some
casts all over the place. There is however the xtensa architecture,
doing its own little weird thing to define its gdbarch_tdep. I did my
best to adapt it, but I can't test those changes.
Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
I wrote this while debugging a problem where the expected unwinder for a
frame wasn't used. It adds messages to show which unwinders are
considered for a frame, why they are not selected (if an exception is
thrown), and finally which unwinder is selected in the end.
To be able to show a meaningful, human-readable name for the unwinders,
add a "name" field to struct frame_unwind, and update all instances to
include a name.
Here's an example of the output:
[frame] frame_unwind_find_by_frame: this_frame=0
[frame] frame_unwind_try_unwinder: trying unwinder "dummy"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "inline"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "jit"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "python"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "amd64 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "i386 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2"
[frame] frame_unwind_try_unwinder: yes
gdb/ChangeLog:
* frame-unwind.h (struct frame_unwind) <name>: New. Update
instances everywhere to include this field.
* frame-unwind.c (frame_unwind_try_unwinder,
frame_unwind_find_by_frame): Add debug messages.
Change-Id: I813f17777422425f0d08b22499817b23922e8ddb
While reviewing another patch, I realized that gdbarch_info_init could
easily be removed in favor of initializing gdbarch_info fields directly
in the struct declaration. The only odd part is the union. I don't
know if it's actually important for it to be zero-initialized, but I
presume it is. I added a constructor to gdbarch_info to take care of
that. A proper solution would be to use std::variant. Or, these could
also be separate fields, the little extra space required wouldn't
matter.
gdb/ChangeLog:
* gdbarch.sh (struct gdbarch_info): Initialize fields, add
constructor.
* gdbarch.h: Re-generate.
* arch-utils.h (gdbarch_info_init): Remove, delete all usages.
* arch-utils.c (gdbarch_info_init): Remove.
Change-Id: I7502e08fe0f278d84eef1667a072e8a97bda5ab5
I wrote a small script to spot a pattern of indentation mistakes I saw
happened in breakpoint.c. And while at it I ran it on all files and
fixed what I found. No behavior changes intended, just indentation and
addition / removal of curly braces.
gdb/ChangeLog:
* Fix some indentation mistakes throughout.
gdbserver/ChangeLog:
* Fix some indentation mistakes throughout.
Change-Id: Ia01990c26c38e83a243d8f33da1d494f16315c6e
AArch64 MTE support in the Linux kernel exposes a new register
through ptrace. This patch adds the required code to support it.
include/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* elf/common.h (NT_ARM_TAGGED_ADDR_CTRL): Define.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c (fetch_mteregs_from_thread): New function.
(store_mteregs_to_thread): New function.
(aarch64_linux_nat_target::fetch_registers): Update to call
fetch_mteregs_from_thread.
(aarch64_linux_nat_target::store_registers): Update to call
store_mteregs_to_thread.
* aarch64-tdep.c (aarch64_mte_register_names): New struct.
(aarch64_cannot_store_register): Handle MTE registers.
(aarch64_gdbarch_init): Initialize and setup MTE registers.
* aarch64-tdep.h (gdbarch_tdep) <mte_reg_base>: New field.
<has_mte>: New method.
* arch/aarch64-linux.h (AARCH64_LINUX_SIZEOF_MTE): Define.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc (aarch64_fill_mteregset): New function.
(aarch64_store_mteregset): New function.
(aarch64_regsets): Add MTE register set entry.
(aarch64_sve_regsets): Add MTE register set entry.
This patch adds a target description and feature "mte" for aarch64.
It includes one new register, tag_ctl, that can be used to configure the
tag generation rules and sync/async modes. It is 64-bit in size.
The patch also adjusts the code that creates the target descriptions at
runtime based on CPU feature checks.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::read_description): Take MTE flag into
account.
Slight refactor to hwcap flag checking.
* aarch64-linux-tdep.c
(aarch64_linux_core_read_description): Likewise.
* aarch64-tdep.c (tdesc_aarch64_list): Add one more dimension for
MTE.
(aarch64_read_description): Add mte_p parameter and update to use it.
Update the documentation.
(aarch64_gdbarch_init): Update call to aarch64_read_description.
* aarch64-tdep.h (aarch64_read_description): Add mte_p parameter.
* arch/aarch64.c: Include ../features/aarch64-mte.c.
(aarch64_create_target_description): Add mte_p parameter and update
the code to use it.
* arch/aarch64.h (aarch64_create_target_description): Add mte_p
parameter.
* features/Makefile (FEATURE_XMLFILES): Add aarch64-mte.xml.
* features/aarch64-mte.c: New file, generated.
* features/aarch64-mte.xml: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-ipa.cc (get_ipa_tdesc): Update call to
aarch64_linux_read_description.
(initialize_low_tracepoint): Likewise.
* linux-aarch64-low.cc (aarch64_target::low_arch_setup): Take MTE flag
into account.
* linux-aarch64-tdesc.cc (tdesc_aarch64_list): Add one more dimension
for MTE.
(aarch64_linux_read_description): Add mte_p parameter and update to
use it.
* linux-aarch64-tdesc.h (aarch64_linux_read_description): Add mte_p
parameter.
Enable displaced stepping over a BR/BLR instruction
Displaced stepping over an instruction executes a instruction in a
scratch area and then manually fixes up the PC address to leave
execution where it would have been if the instruction were in its
original location.
The BR instruction does not need modification in order to run correctly
at a different address, but the displaced step fixup method should not
manually adjust the PC since the BR instruction sets that value already.
The BLR instruction should also avoid such a fixup, but must also have
the link register modified to point to just after the original code
location rather than back to the scratch location.
This patch adds the above functionality.
We add this functionality by modifying aarch64_displaced_step_others
rather than by adding a new visitor method to aarch64_insn_visitor.
We choose this since it seems that visitor approach is designed
specifically for PC relative instructions (which must always be modified
when executed in a different location).
It seems that the BR and BLR instructions are more like the RET
instruction which is already handled specially in
aarch64_displaced_step_others.
This also means the gdbserver code to relocate an instruction when
creating a fast tracepoint does not need to be modified, since nothing
special is needed for the BR and BLR instructions there.
Regression tests showed nothing untoward on native aarch64 (though it
took a while for me to get the testcase to account for PIE).
------#####
Original observed (mis)behaviour before was that displaced stepping over
a BR or BLR instruction would not execute the function they called.
Most easily seen by putting a breakpoint with a condition on such an
instruction and a print statement in the functions they called.
When run with the breakpoint enabled the function is not called and
"numargs called" is not printed.
When run with the breakpoint disabled the function is called and the
message is printed.
--- GDB Session
~ [15:57:14] % gdb ../using-blr
Reading symbols from ../using-blr...done.
(gdb) disassemble blr_call_value
Dump of assembler code for function blr_call_value:
...
0x0000000000400560 <+28>: blr x2
...
0x00000000004005b8 <+116>: ret
End of assembler dump.
(gdb) break *0x0000000000400560
Breakpoint 1 at 0x400560: file ../using-blr.c, line 22.
(gdb) condition 1 10 == 0
(gdb) run
Starting program: /home/matmal01/using-blr
[Inferior 1 (process 33279) exited with code 012]
(gdb) disable 1
(gdb) run
Starting program: /home/matmal01/using-blr
numargs called
[Inferior 1 (process 33289) exited with code 012]
(gdb)
Test program:
---- using-blr ----
\#include <stdio.h>
typedef int (foo) (int, int);
typedef void (bar) (int, int);
struct sls_testclass {
foo *x;
bar *y;
int left;
int right;
};
__attribute__ ((noinline))
int blr_call_value (struct sls_testclass x)
{
int retval = x.x(x.left, x.right);
if (retval % 10)
return 100;
return 9;
}
__attribute__ ((noinline))
int blr_call (struct sls_testclass x)
{
x.y(x.left, x.right);
if (x.left % 10)
return 100;
return 9;
}
int
numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("numargs called\n");
return 10;
}
void
altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("altfunc called\n");
}
int main(int argc, char **argv)
{
struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 };
if (argc > 2)
{
blr_call (x);
}
else
blr_call_value (x);
return 10;
}
With the new member functions for struct trad_frame_saved_reg, there is no
need to invoke some of the set/get functions anymore. This patch removes
those and adjusts all callers.
Even though the most natural initial state of a saved register value is
UNKNOWN, there are target backends relying on the previous initial state
of REALREG set to a register's own number. I noticed this in at least a
couple targets: aarch64 and riscv.
Because of that, I decided to keep the reset function that sets the set of
register values to REALREG. I can't exercise all the targets to make sure
the initial state change won't break things, hence why it is risky to change
the default.
Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04.
gdb/ChangeLog
2021-01-19 Luis Machado <luis.machado@linaro.org>
* trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate
memory and save data.
(trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes)
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p): Remove.
(trad_frame_reset_saved_regs): Adjust documentation.
* trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a
constructor and reset the state of the registers.
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p, trad_frame_set_value)
(trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes): Remove.
(trad_frame_set_reg_realreg): Update to call member function.
(trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.
* aarch64-tdep.c (aarch64_analyze_prologue)
(aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1)
(aarch64_prologue_prev_register): Update to use member functions.
* alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise.
* alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise.
* arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise.
* arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache)
(arm_make_epilogue_frame_cache): Likewise.
* avr-tdep.c (avr_frame_unwind_cache)
(avr_frame_prev_register): Likewise.
* cris-tdep.c (cris_scan_prologue): Likewise.
* csky-tdep.c (csky_frame_unwind_cache): Likewise.
* frv-tdep.c (frv_analyze_prologue): Likewise.
* hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise.
* lm32-tdep.c (lm32_frame_cache): Likewise.
* m32r-tdep.c (m32r_frame_unwind_cache): Likewise.
* m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise.
* mips-tdep.c (set_reg_offset, mips_insn16_frame_cache)
(mips_micro_frame_cache, mips_insn32_frame_cache): Likewise.
(reset_saved_regs): Adjust to set realreg.
* riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to
call member functions.
* rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache)
* s390-tdep.c (s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache): Likewise.
* score-tdep.c (score7_analyze_prologue)
(score3_analyze_prologue, score_make_prologue_cache): Likewise.
* sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise.
* sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise.
* sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise.
* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue)
(tilegx_frame_cache): Likewise.
* v850-tdep.c (v850_frame_cache): Likewise.
* vax-tdep.c (vax_frame_cache): Likewise.
I haven't tried this on an actual aarch64 machine, but I am able to
exercise it like this:
(gdb) set debug aarch64
(gdb) maintenance selftest aa
Running selftest aarch64-analyze-prologue.
[aarch64] aarch64_analyze_prologue: prologue analysis gave up addr=0x14 opcode=0xf94013e0
Running selftest aarch64-process-record.
Ran 2 unit tests, 0 failed
gdb/ChangeLog:
* arch/aarch64-insn.h (aarch64_debug_printf): New.
* arch/aarch64-insn.c: Use aarch64_debug_printf.
* aarch64-tdep.c: Use aarch64_debug_printf.
Change-Id: Ifdb40e2816ab8e55a9aabb066d1833d9b5a46094
The following patch drops the overloading going on with the trad_frame_saved_reg
struct and defines a new struct with a KIND enum and a union of different
fields.
The new struct looks like this:
struct trad_frame_saved_reg
{
setters/getters
...
private:
trad_frame_saved_reg_kind m_kind;
union {
LONGEST value;
int realreg;
LONGEST addr;
const gdb_byte *value_bytes;
} m_reg;
};
And the enums look like this:
/* Describes the kind of encoding a stored register has. */
enum class trad_frame_saved_reg_kind
{
/* Register value is unknown. */
UNKNOWN = 0,
/* Register value is a constant. */
VALUE,
/* Register value is in another register. */
REALREG,
/* Register value is at an address. */
ADDR,
/* Register value is a sequence of bytes. */
VALUE_BYTES
};
The patch also adds setters/getters and updates all the users of the old
struct.
It is worth mentioning that due to the previous overloaded nature of the
fields, some tdep files like to store negative offsets and indexes in the ADDR
field, so I kept the ADDR as LONGEST instead of CORE_ADDR. Those cases may
be better supported by a new enum entry.
I have not addressed those cases in this patch to prevent unwanted breakage,
given I have no way to test some of the targets. But it would be nice to
clean those up eventually.
The change to frame-unwind.* is to constify the parameter being passed to the
unwinding functions, given we now accept a "const gdb_byte *" for value bytes.
Tested on aarch64-linux/Ubuntu 20.04/18.04 and by building GDB with
--enable-targets=all.
gdb/ChangeLog:
2021-01-04 Luis Machado <luis.machado@linaro.org>
Update all users of trad_frame_saved_reg to use the new member
functions.
Remote all struct keywords from declarations of trad_frame_saved_reg
types, except on forward declarations.
* aarch64-tdep.c: Update.
* alpha-mdebug-tdep.c: Update.
* alpha-tdep.c: Update.
* arc-tdep.c: Update.
* arm-tdep.c: Update.
* avr-tdep.c: Update.
* cris-tdep.c: Update.
* csky-tdep.c: Update.
* frv-tdep.c: Update.
* hppa-linux-tdep.c: Update.
* hppa-tdep.c: Update.
* hppa-tdep.h: Update.
* lm32-tdep.c: Update.
* m32r-linux-tdep.c: Update.
* m32r-tdep.c: Update.
* m68hc11-tdep.c: Update.
* mips-tdep.c: Update.
* moxie-tdep.c: Update.
* riscv-tdep.c: Update.
* rs6000-tdep.c: Update.
* s390-linux-tdep.c: Update.
* s390-tdep.c: Update.
* score-tdep.c: Update.
* sparc-netbsd-tdep.c: Update.
* sparc-sol2-tdep.c: Update.
* sparc64-fbsd-tdep.c: Update.
* sparc64-netbsd-tdep.c: Update.
* sparc64-obsd-tdep.c: Update.
* sparc64-sol2-tdep.c: Update.
* tilegx-tdep.c: Update.
* v850-tdep.c: Update.
* vax-tdep.c: Update.
* frame-unwind.c (frame_unwind_got_bytes): Make parameter const.
* frame-unwind.h (frame_unwind_got_bytes): Likewise.
* trad-frame.c: Update.
Remove TF_REG_* enum.
(trad_frame_alloc_saved_regs): Add a static assertion to check for
a trivially-constructible struct.
(trad_frame_reset_saved_regs): Adjust to use member function.
(trad_frame_value_p): Likewise.
(trad_frame_addr_p): Likewise.
(trad_frame_realreg_p): Likewise.
(trad_frame_value_bytes_p): Likewise.
(trad_frame_set_value): Likewise.
(trad_frame_set_realreg): Likewise.
(trad_frame_set_addr): Likewise.
(trad_frame_set_unknown): Likewise.
(trad_frame_set_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.
* trad-frame.h: Update.
(trad_frame_saved_reg_kind): New enum.
(struct trad_frame_saved_reg) <addr, realreg, data>: Remove.
<m_kind, m_reg>: New member fields.
<set_value, set_realreg, set_addr, set_unknown, set_value_bytes>
<kind, value, realreg, addr, value_bytes, is_value, is_realreg>
<is_addr, is_unknown, is_value_bytes>: New member functions.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
I noticed this failure in gdb.reverse/reverse-insn.exp:
FAIL: gdb.reverse/insn-reverse.exp: adv_simd_vect_shift: compare registers on insn 0:fcvtzs s0, s0, #1
Turns out we're not recording changes to the FPSR. The SIMD/FP data
instructions may set bits in the FPSR, so it needs to be recorded for
proper reverse operations.
gdb/ChangeLog:
2020-12-16 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (aarch64_record_data_proc_simd_fp): Record FPSR.
When UBSan is enabled, I noticed runtime errors complaining of shifting
of negative numbers.
This patch fixes this by reusing existing macros from the ARM port.
It also removes unused macros from AArch64's port.
gdb/ChangeLog:
2020-12-04 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (submask, bit, bits): Remove.
* arch/aarch64-insn.c (extract_signed_bitfield): Remove.
(aarch64_decode_adr, aarch64_decode_b aarch64_decode_bcond)
(aarch64_decode_cb, aarch64_decode_tb)
(aarch64_decode_ldr_literal): Use sbits to extract a signed
immediate.
* arch/aarch64-insn.h (submask, bits, bit, sbits): New macros.
Move all debug prints of the "displaced" category to use a new
displaced_debug_printf macro, like what was done for infrun and others
earlier.
The debug output for one displaced step one amd64 looks like:
[displaced] displaced_step_prepare_throw: stepping process 3367044 now
[displaced] displaced_step_prepare_throw: saved 0x555555555042: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] amd64_displaced_step_copy_insn: copy 0x555555555131->0x555555555042: b8 00 00 00 00 5d c3 0f 1f 84 00 00 00 00 00 f3
[displaced] displaced_step_prepare_throw: displaced pc to 0x555555555042
[displaced] resume_1: run 0x555555555042: b8 00 00 00
[displaced] displaced_step_restore: restored process 3367044 0x555555555042
[displaced] amd64_displaced_step_fixup: fixup (0x555555555131, 0x555555555042), insn = 0xb8 0x00 ...
[displaced] amd64_displaced_step_fixup: relocated %rip from 0x555555555047 to 0x555555555136
On test case needed to be updated because it relied on the specific
formatting of the message.
gdb/ChangeLog:
* infrun.h (displaced_debug_printf): New macro. Replace
displaced debug prints throughout to use it.
(displaced_debug_printf_1): New declaration.
(displaced_step_dump_bytes): Return string, remove ui_file
parameter, update all callers.
* infrun.c (displaced_debug_printf_1): New function.
(displaced_step_dump_bytes): Return string, remove ui_file
parameter
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.exp: Update displaced step debug
expected output.
Change-Id: Ie78837f56431f6f98378790ba1e6051337bf6533
I noticed that the closure parameter of
gdbarch_displaced_step_hw_singlestep is never used by any
implementation of the method, so this patch removes it.
gdb/ChangeLog:
* gdbarch.sh (displaced_step_hw_singlestep): Remove closure
parameter.
* aarch64-tdep.c (aarch64_displaced_step_hw_singlestep):
Likewise.
* aarch64-tdep.h (aarch64_displaced_step_hw_singlestep):
Likewise.
* arch-utils.c (default_displaced_step_hw_singlestep):
Likewise.
* arch-utils.h (default_displaced_step_hw_singlestep):
Likewise.
* rs6000-tdep.c (ppc_displaced_step_hw_singlestep):
Likewise.
* s390-tdep.c (s390_displaced_step_hw_singlestep):
Likewise.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* infrun.c (resume_1): Adjust.
Change-Id: I7354f0b22afc2692ebff0cd700a462db8f389fc1
While working on something else, I noticed that tdesc_data_cleanup
took a void* parameter. Looking more into this, I found that
tdesc_use_registers expected a transfer of ownership.
I think it's better to express this sort of thing via the type system,
when possible. This patch changes tdesc_data_alloc to return a unique
pointer, changes tdesc_use_registers to accept an rvalue reference,
and then adapts all the users.
Note that a deleter structure is introduced to avoid having to move
tdesc_arch_data to the header file.
2020-09-17 Tom Tromey <tromey@adacore.com>
* tic6x-tdep.c (tic6x_gdbarch_init): Update.
* target-descriptions.h (struct tdesc_arch_data_deleter): New.
(tdesc_arch_data_up): New typedef.
(tdesc_use_registers, tdesc_data_alloc): Update.
(tdesc_data_cleanup): Don't declare.
* target-descriptions.c (tdesc_data_alloc): Return a
tdesc_arch_data_up.
(tdesc_arch_data_deleter::operator()): Rename from
tdesc_data_cleanup. Change argument type.
(tdesc_use_registers): Change early_data to an rvalue reference.
(tdesc_use_registers): Don't use delete.
* sparc-tdep.c (sparc32_gdbarch_init): Update.
* s390-tdep.c (s390_gdbarch_init): Update.
* rx-tdep.c (rx_gdbarch_init): Update.
* rs6000-tdep.c (rs6000_gdbarch_init): Update.
* riscv-tdep.c (riscv_gdbarch_init): Update.
* or1k-tdep.c (or1k_gdbarch_init): Update.
* nios2-tdep.c (nios2_gdbarch_init): Update.
* nds32-tdep.c (nds32_gdbarch_init): Update.
* mips-tdep.c (mips_gdbarch_init): Update.
* microblaze-tdep.c (microblaze_gdbarch_init): Update.
* m68k-tdep.c (m68k_gdbarch_init): Update.
* i386-tdep.c (i386_gdbarch_init): Update.
* arm-tdep.c (arm_gdbarch_init): Update.
* arc-tdep.c (arc_tdesc_init): Update.
(arc_gdbarch_init): Update.
* aarch64-tdep.c (aarch64_gdbarch_init): Update.
I initially noticed the problem with the addition of
gdb.dwarf2/dw2-line-number-zero.exp. The following failures showed up:
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
They happen because AArch64's prologue analyzer skips too many instructions
and ends up indicating a stopping point further into user code.
Dump of assembler code for function bar1:
0x00000000000006f8 <+0>: stp x29, x30, [sp, #-16]!
0x00000000000006fc <+4>: mov x29, sp
0x0000000000000700 <+8>: mov w0, #0x1 // #1
0x0000000000000704 <+12>: bl 0x6e4 <foo>
0x0000000000000708 <+16>: mov w0, #0x2 // #2
We should've stopped at 0x700, but the analyzer actually skips
that instruction and stops at 0x704. Then GDB ends up adjusting
the address further, and pushes the stopping point to 0x708 based on the
SAL information.
I'm not sure if this adjustment to 0x708 is correct though, as it ends up
skipping past a branch. But I'm leaving that aside for now.
One other complicating factor is that GCC seems to be hoisting up instructions
from user code, mixing them up with prologue instructions.
The following patch adjusts the heuristics a little bit, and tracks when the
SP and FP get used. If we notice an instruction that is not supposed to be
in the prologue, and this happens *after* SP/FP adjustments and saving of
registers, we stop the analysis.
This means, for PR26310, that we will now stop at 0x700.
I've also added a few more unit tests to make sure the updated behavior is
validated.
gdb/ChangeLog:
2020-08-10 Luis Machado <luis.machado@linaro.org>
PR gdb/26310
* aarch64-tdep.c (aarch64_analyze_prologue): Track use of SP/FP and
act accordingly.
(aarch64_analyze_prologue_test): Add more unit tests to exercise
movz/str/stur/stp skipping behavior.
Remove the `TYPE_FIELD_TYPE` macro, changing all the call sites to use
`type::field` and `field::type` directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD_TYPE): Remove. Change all call sites
to use type::field and field::type instead.
Change-Id: Ifda6226a25c811cfd334a756a9fbc5c0afdddff3
Replace all uses of it by type::field.
Note that since type::field returns a reference to the field, some spots
are used to assign the whole field structure. See ctfread.c, function
attach_fields_to_type, for example. This is the same as was happening
with the macro, so I don't think it's a problem, but if anybody sees a
really nicer way to do this, now could be a good time to implement it.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD): Remove. Replace all uses with
type::field.
Remove `TYPE_NFIELDS`, changing all the call sites to use
`type::num_fields` directly. This is quite a big diff, but this was
mostly done using sed and coccinelle. A few call sites were done by
hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NFIELDS): Remove. Change all cal sites to use
type::num_fields instead.
Change-Id: Ib73be4c36f9e770e0f729bac3b5257d7cb2f9591
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
Just a trivial typo fix in a comment.
gdb/ChangeLog
2020-02-25 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (aarch64_vnv_type): Fix comment typo.
To help with readability, add the type displaced_step_closure_up, an
alias for std::unique_ptr<displaced_step_closure>, and use it throughout
the code base.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_displaced_step_copy_insn): Use
displaced_step_closure_up.
* aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise.
(struct displaced_step_closure_up):
* amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise.
* amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise.
* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn):
Likewise.
* gdbarch.sh (displaced_step_copy_insn): Likewise.
* gdbarch.c, gdbarch.h: Re-generate.
* i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Use
displaced_step_closure_up.
* i386-tdep.c (i386_displaced_step_copy_insn): Likewise.
* i386-tdep.h (i386_displaced_step_copy_insn): Likewise.
* infrun.h (displaced_step_closure_up): New type alias.
(struct displaced_step_inferior_state) <step_closure>: Change
type to displaced_step_closure_up.
* rs6000-tdep.c (ppc_displaced_step_copy_insn): Use
displaced_step_closure_up.
* s390-tdep.c (s390_displaced_step_copy_insn): Likewise.
This callback dynamically allocates a specialized displaced_step_closure, and
gives the ownership of the object to its caller. So I think it would make
sense for the callback to return an std::unique_ptr, this is what this patch
implements.
gdb/ChangeLog:
* gdbarch.sh (displaced_step_copy_insn): Change return type to an
std::unique_ptr.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* infrun.c (displaced_step_prepare_throw): Adjust to std::unique_ptr
change.
* aarch64-tdep.c (aarch64_displaced_step_copy_insn): Change return
type to std::unique_ptr.
* aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise.
* amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise.
* amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise.
* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Likewise.
* i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Likewise.
* i386-tdep.c (i386_displaced_step_copy_insn): Likewise.
* i386-tdep.h (i386_displaced_step_copy_insn): Likewise.
* rs6000-tdep.c (ppc_displaced_step_copy_insn): Likewise.
* s390-tdep.c (s390_displaced_step_copy_insn): Likewise.
New in v3:
- Code cleanups based on reviews.
New in v2:
- Fixed misc problems based on reviews.
- Switched to using gdbarch_program_breakpoint_here_p as opposed to
gdbarch_insn_is_breakpoint.
- Fixed matching of brk instructions. Previously the mask was incorrect, which
was showing up as a few failures in the testsuite. Now it is clean.
- New testcase (separate patch).
- Moved program_breakpoint_here () to arch-utils.c and made it the default
implementation of gdbarch_program_breakpoint_here_p.
--
It was reported to me that program breakpoints (permanent ones inserted into
the code itself) other than the one GDB uses for AArch64 (0xd4200000) do not
generate visible stops when continuing, and GDB will continue spinning
infinitely.
This happens because GDB, upon hitting one of those program breakpoints, thinks
the SIGTRAP came from a delayed breakpoint hit...
(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk #0x90f
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 14198)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 14198
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14198.14198.0 [process 14198],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
...
... which is not the case.
If the program breakpoint is one GDB recognizes, then it will stop when it
hits it.
(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk #0x0
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 14193)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 14193
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14193] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 14193.14193.0 [process 14193],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: random signal (GDB_SIGNAL_TRAP)
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: process 14193 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun: process 14193 not executing
infrun: stop_all_threads done
Program received signal SIGTRAP, Trace/breakpoint trap.
problem_function () at brk_0.c:7
7 asm("brk %0\n\t" ::"n"(0x0));
infrun: infrun_async(0)
Otherwise GDB will keep trying to resume the inferior and will keep
seeing the SIGTRAP's, without stopping.
To the user it appears GDB has gone into an infinite loop, interruptible only
by Ctrl-C.
Also, windbg seems to use a different variation of AArch64 breakpoint compared
to GDB. This causes problems when debugging Windows on ARM binaries, when
program breakpoints are being used.
The proposed patch creates a new gdbarch method (gdbarch_program_breakpoint_here_p)
that tells GDB whether the underlying instruction is a breakpoint instruction
or not.
This is more general than only checking for the instruction GDB uses as
breakpoint.
The existing logic is still preserved for targets that do not implement this
new gdbarch method.
The end result is like so:
(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk #0x90f
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 16417)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 16417
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 16417] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 16417.16417.0 [process 16417],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: random signal (GDB_SIGNAL_TRAP)
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: process 16417 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun: process 16417 not executing
infrun: stop_all_threads done
Program received signal SIGTRAP, Trace/breakpoint trap.
problem_function () at brk.c:7
7 asm("brk %0\n\t" ::"n"(0x900 + 0xf));
infrun: infrun_async(0)
gdb/ChangeLog:
2020-01-29 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (BRK_INSN_MASK): Define to 0xffe0001f.
(BRK_INSN_MASK): Define to 0xd4200000.
(aarch64_program_breakpoint_here_p): New function.
(aarch64_gdbarch_init): Set gdbarch_program_breakpoint_here_p hook.
* arch-utils.c (default_program_breakpoint_here_p): Moved from
breakpoint.c.
* arch-utils.h (default_program_breakpoint_here_p): Moved from
breakpoint.h
* breakpoint.c (bp_loc_is_permanent): Changed return type to bool and
call gdbarch_program_breakpoint_here_p.
(program_breakpoint_here): Moved to arch-utils.c, renamed to
default_program_breakpoint_here_p, changed return type to bool and
simplified.
* breakpoint.h (program_breakpoint_here): Moved prototype to
arch-utils.h, renamed to default_program_breakpoint_here_p and changed
return type to bool.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (program_breakpoint_here_p): New method.
* infrun.c (handle_signal_stop): Call
gdbarch_program_breakpoint_here_p.
As suggested, the cond variable is really supposed to be a bool. So,
make it so.
gdb/ChangeLog:
2020-01-21 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (struct aarch64_displaced_step_closure)
<cond>: Change type to bool.
(aarch64_displaced_step_b_cond): Update cond to use bool type.
(aarch64_displaced_step_cb): Likewise.
(aarch64_displaced_step_tb): Likewise.
While debugging the step-over-syscall problem, i wanted to see a bit more
debugging output to try to determine the root cause.
This patch does this.
gdb/ChangeLog:
2020-01-21 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (aarch64_displaced_step_fixup): Add more debugging
output.
In particular, this one:
FAIL: gdb.base/step-over-syscall.exp: fork: displaced=on: check_pc_after_cross_syscall: single step over fork final pc
When ptrace fork event reporting is enabled, GDB gets a PTRACE_EVENT_FORK
event whenever the inferior executes the fork syscall.
Then the logic is that GDB needs to step the inferior yet again in order to
receive a predetermined SIGTRAP, but no execution takes place because the
signal was already queued for delivery. That means the PC should stay the same.
I noticed the aarch64 code is currently adjusting the PC in this situation,
making the inferior skip an instruction without executing it.
The following change checks if we did not execute the instruction
(pc - to == 0), making proper adjustments for such case.
Regression tested on aarch64-linux-gnu on the tryserver.
gdb/ChangeLog:
2020-01-21 Luis Machado <luis.machado@linaro.org>
* aarch64-tdep.c (struct aarch64_displaced_step_closure )
<pc_adjust>: Adjust the documentation.
(aarch64_displaced_step_fixup): Check if PC really moved before
adjusting it.
Keith Seitz