Commit Graph

8 Commits

Author SHA1 Message Date
Simon Marchi
ec45252592 gdb: move store/extract integer functions to extract-store-integer.{c,h}
Move the declarations out of defs.h, and the implementations out of
findvar.c.

I opted for a new file, because this functionality of converting
integers to bytes and vice-versa seems a bit to generic to live in
findvar.c.

Change-Id: I524858fca33901ee2150c582bac16042148d2251
Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22 21:34:19 -04:00
Simon Marchi
18d2988e5d gdb, gdbserver, gdbsupport: remove includes of early headers
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them.  Remove all the inclusions of these files I could find.  Update
the generation scripts where relevant.

Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26 21:13:22 -04:00
Andrew Burgess
1d506c26d9 Update copyright year range in header of all files managed by GDB
This commit is the result of the following actions:

  - Running gdb/copyright.py to update all of the copyright headers to
    include 2024,

  - Manually updating a few files the copyright.py script told me to
    update, these files had copyright headers embedded within the
    file,

  - Regenerating gdbsupport/Makefile.in to refresh it's copyright
    date,

  - Using grep to find other files that still mentioned 2023.  If
    these files were updated last year from 2022 to 2023 then I've
    updated them this year to 2024.

I'm sure I've probably missed some dates.  Feel free to fix them up as
you spot them.
2024-01-12 15:49:57 +00:00
Joel Brobecker
213516ef31 Update copyright year range in header of all files managed by GDB
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
2023-01-01 17:01:16 +04:00
Andrew Burgess
08106042d9 gdb: move the type cast into gdbarch_tdep
I built GDB for all targets on a x86-64/GNU-Linux system, and
then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run"
the binary on the native target.  I got this error:

  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386").
  (gdb) file /tmp/hello.rv32.exe
  Reading symbols from /tmp/hello.rv32.exe...
  (gdb) show architecture
  The target architecture is set to "auto" (currently "riscv:rv32").
  (gdb) run
  Starting program: /tmp/hello.rv32.exe
  ../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.

What's going on here is this; initially the architecture is i386, this
is based on the default architecture, which is set based on the native
target.  After loading the RISC-V executable the architecture of the
current inferior is updated based on the architecture of the
executable.

When we "run", GDB does a fork & exec, with the inferior being
controlled through ptrace.  GDB sees an initial stop from the inferior
as soon as the inferior comes to life.  In response to this stop GDB
ends up calling save_stop_reason (linux-nat.c), which ends up trying
to read register from the inferior, to do this we end up calling
target_ops::fetch_registers, which, for the x86-64 native target,
calls amd64_linux_nat_target::fetch_registers.

After this I eventually end up in i387_supply_fxsave, different x86
based targets will end in different functions to fetch registers, but
it doesn't really matter which function we end up in, the problem is
this line, which is repeated in many places:

  i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);

The problem here is that the ARCH in this line comes from the current
inferior, which, as we discussed above, will be a RISC-V gdbarch, the
tdep field will actually be of type riscv_gdbarch_tdep, not
i386_gdbarch_tdep.  After this cast we are relying on undefined
behaviour, in my case I happen to trigger an assert, but this might
not always be the case.

The thing I tried that exposed this problem was of course, trying to
start an executable of the wrong architecture on a native target.  I
don't think that the correct solution for this problem is to detect,
at the point of cast, that the gdbarch_tdep object is of the wrong
type, but, I did wonder, is there a way that we could protect
ourselves from incorrectly casting the gdbarch_tdep object?

I think that there is something we can do here, and this commit is the
first step in that direction, though no actual check is added by this
commit.

This commit can be split into two parts:

 (1) In gdbarch.h and arch-utils.c.  In these files I have modified
 gdbarch_tdep (the function) so that it now takes a template argument,
 like this:

    template<typename TDepType>
    static inline TDepType *
    gdbarch_tdep (struct gdbarch *gdbarch)
    {
      struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch);
      return static_cast<TDepType *> (tdep);
    }

  After this change we are no better protected, but the cast is now
  done within the gdbarch_tdep function rather than at the call sites,
  this leads to the second, much larger change in this commit,

  (2) Everywhere gdbarch_tdep is called, we make changes like this:

    -  i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
    +  i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch);

There should be no functional change after this commit.

In the next commit I will build on this change to add an assertion in
gdbarch_tdep that checks we are casting to the correct type.
2022-07-21 15:19:42 +01:00
Joel Brobecker
4a94e36819 Automatic Copyright Year update after running gdb/copyright.py
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.
2022-01-01 19:13:23 +04:00
Simon Marchi
345bd07cce gdb: fix gdbarch_tdep ODR violation
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
2021-11-15 11:29:39 -05:00
Andrew Burgess
9b715c68e8 gdb/arm: add support for bare-metal core dumps
This commit adds support for bare metal core dumps on the ARM target,
and is based off of this patch submitted to the mailing list:

  https://sourceware.org/pipermail/gdb-patches/2020-October/172845.html

Compared to the version linked above this version is updated to take
account of recent changes to the core dump infrastructure in GDB,
there is now more shared infrastructure for core dumping within GDB,
and also some common bare metal core dumping infrastructure.  As a
result this patch is smaller than the original proposed patch.

Further, the original patch included some unrelated changes to the
simulator that have been removed from this version.

I have written a ChangeLog entry as the original patch was missing
one.

I have done absolutely no testing of this patch.  It is based on the
original submitted patch, which I assume was tested, but after my
modifications things might have been broken, however, the original
patch author has tested this version and reported it as being good:

  https://sourceware.org/pipermail/gdb-patches/2021-May/178900.html

The core dump format is based around generating an ELF containing
sections for the writable regions of memory that a user could be
using.  Which regions are dumped rely on GDB's existing common core
dumping code, GDB will attempt to figure out the stack and heap as
well as copying out writable data sections as identified by the
original ELF.

Register information is added to the core dump using notes, just as it
is for Linux of FreeBSD core dumps.  The note types used consist of
the 2 basic types you would expect in a OS based core dump,
NT_PRPSINFO, NT_PRSTATUS, along with the architecture specific
NT_ARM_VFP note.

The data layouts for each note type are described below, in all cases,
all padding fields should be set to zero.

Note NT_PRPSINFO is optional.  Its data layout is:

  struct prpsinfo_t
  {
    uint8_t padding[28];
    char fname[16];
    char psargs[80];
  }

Field 'fname' - null terminated string consisting of the basename of
    (up to the fist 15 characters of) the executable.  Any additional
    space should be set to zero.  If there's no executable name then
    this field can be set to all zero.

Field 'psargs' - a null terminated string up to 80 characters in
    length.  Any additional space should be filled with zero.  This
    field contains the full executable path and any arguments passed
    to the executable.  If there's nothing sensible to write in this
    field then fill it with zero.

Note NT_PRSTATUS is required, its data layout is:

  struct prstatus_t
  {
    uint8_t padding_1[12];
    uint16_t sig;
    uint8_t padding_2[10];
    uint32_t thread_id;
    uint8_t padding_3[44];
    uint32_t gregs[18];
  }

Field 'sig' - the signal that stopped this thread.  It's implementation
    defined what this field actually means.  Within GDB this will be
    the signal number that the remote target reports as the stop
    reason for this thread.

Field 'thread_is' - the thread id for this thread.  It's implementation
    defined what this field actually means.  Within GDB this will be
    thread thread-id that is assigned to each remote thread.

Field 'gregs' - holds the general purpose registers $a1 through to $pc
    at indices 0 to 15.  At index 16 the program status register.
    Index 17 should be set to zero.

Note NT_ARM_VFP is optional, its data layout is:

  armvfp_t
  {
    uint64_t regs[32];
    uint32_t fpscr;
  }

Field 'regs' - holds the 32 d-registers 0 to 31 in order.

Field 'fpscr' - holds the fpscr register.

The rules for ordering the notes is the same as for Linux.  The
NT_PRSTATUS note must come before any other notes about additional
register sets.  And for multi-threaded targets all registers for a
single thread should be grouped together.  This is because only
NT_PRSTATUS includes a thread-id, all additional register notes after
a NT_PRSTATUS are assumed to belong to the same thread until a
different NT_PRSTATUS is seen.

gdb/ChangeLog:

	PR gdb/14383
	* Makefile.in (ALL_TARGET_OBS): Add arm-none-tdep.o.
	(ALLDEPFILES): Add arm-none-tdep.c
	* arm-none-tdep.c: New file.
	* configure.tgt (arm*-*-*): Add arm-none-tdep.o to cpu_obs.
2021-06-01 09:56:22 +01:00