2004-12-11 10:02:01 +08:00
|
|
|
/* Target-dependent interface for Matsushita MN10300 for GDB, the GNU debugger.
|
|
|
|
|
|
2024-01-12 23:30:44 +08:00
|
|
|
Copyright (C) 1996-2024 Free Software Foundation, Inc.
|
2004-12-11 10:02:01 +08:00
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2007-08-24 02:08:50 +08:00
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
2004-12-11 10:02:01 +08:00
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
2007-08-24 02:08:50 +08:00
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
2004-12-11 10:02:01 +08:00
|
|
|
|
2019-01-28 03:51:36 +08:00
|
|
|
#ifndef MN10300_TDEP_H
|
|
|
|
|
#define MN10300_TDEP_H
|
|
|
|
|
|
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-16 00:29:39 +08:00
|
|
|
#include "gdbarch.h"
|
|
|
|
|
|
2005-03-05 10:01:40 +08:00
|
|
|
enum {
|
|
|
|
|
E_D0_REGNUM = 0,
|
|
|
|
|
E_D1_REGNUM = 1,
|
|
|
|
|
E_D2_REGNUM = 2,
|
|
|
|
|
E_D3_REGNUM = 3,
|
|
|
|
|
E_A0_REGNUM = 4,
|
|
|
|
|
E_A1_REGNUM = 5,
|
|
|
|
|
E_A2_REGNUM = 6,
|
|
|
|
|
E_A3_REGNUM = 7,
|
|
|
|
|
E_SP_REGNUM = 8,
|
|
|
|
|
E_PC_REGNUM = 9,
|
|
|
|
|
E_MDR_REGNUM = 10,
|
|
|
|
|
E_PSW_REGNUM = 11,
|
|
|
|
|
E_LIR_REGNUM = 12,
|
|
|
|
|
E_LAR_REGNUM = 13,
|
|
|
|
|
E_MDRQ_REGNUM = 14,
|
|
|
|
|
E_E0_REGNUM = 15,
|
|
|
|
|
E_E1_REGNUM = 16,
|
|
|
|
|
E_E2_REGNUM = 17,
|
|
|
|
|
E_E3_REGNUM = 18,
|
|
|
|
|
E_E4_REGNUM = 19,
|
|
|
|
|
E_E5_REGNUM = 20,
|
|
|
|
|
E_E6_REGNUM = 21,
|
|
|
|
|
E_E7_REGNUM = 22,
|
2005-09-03 06:53:35 +08:00
|
|
|
E_E8_REGNUM = 23,
|
|
|
|
|
E_E9_REGNUM = 24,
|
|
|
|
|
E_E10_REGNUM = 25,
|
2005-03-05 10:01:40 +08:00
|
|
|
E_MCRH_REGNUM = 26,
|
|
|
|
|
E_MCRL_REGNUM = 27,
|
|
|
|
|
E_MCVF_REGNUM = 28,
|
2005-09-03 06:53:35 +08:00
|
|
|
E_FPCR_REGNUM = 29,
|
2005-09-09 06:48:56 +08:00
|
|
|
E_FS0_REGNUM = 32
|
2005-03-05 10:01:40 +08:00
|
|
|
};
|
|
|
|
|
|
2005-04-19 07:15:00 +08:00
|
|
|
enum movm_register_bits {
|
|
|
|
|
movm_exother_bit = 0x01,
|
|
|
|
|
movm_exreg1_bit = 0x02,
|
|
|
|
|
movm_exreg0_bit = 0x04,
|
|
|
|
|
movm_other_bit = 0x08,
|
|
|
|
|
movm_a3_bit = 0x10,
|
|
|
|
|
movm_a2_bit = 0x20,
|
|
|
|
|
movm_d3_bit = 0x40,
|
|
|
|
|
movm_d2_bit = 0x80
|
|
|
|
|
};
|
|
|
|
|
|
2011-01-09 11:20:33 +08:00
|
|
|
/* Values for frame_info.status. */
|
2005-04-19 07:15:00 +08:00
|
|
|
|
|
|
|
|
enum frame_kind {
|
|
|
|
|
MY_FRAME_IN_SP = 0x1,
|
|
|
|
|
MY_FRAME_IN_FP = 0x2,
|
|
|
|
|
NO_MORE_FRAMES = 0x4
|
|
|
|
|
};
|
|
|
|
|
|
2011-01-09 11:20:33 +08:00
|
|
|
/* mn10300 private data. */
|
2022-07-25 19:07:11 +08:00
|
|
|
struct mn10300_gdbarch_tdep : gdbarch_tdep_base
|
2004-12-11 10:02:01 +08:00
|
|
|
{
|
|
|
|
|
int am33_mode;
|
|
|
|
|
};
|
|
|
|
|
|
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-16 00:29:39 +08:00
|
|
|
static inline int
|
|
|
|
|
get_am33_mode (gdbarch *arch)
|
|
|
|
|
{
|
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-05-19 20:20:17 +08:00
|
|
|
mn10300_gdbarch_tdep *tdep = gdbarch_tdep<mn10300_gdbarch_tdep> (arch);
|
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-16 00:29:39 +08:00
|
|
|
return tdep->am33_mode;
|
|
|
|
|
}
|
2019-01-28 03:51:36 +08:00
|
|
|
|
|
|
|
|
#endif /* MN10300_TDEP_H */
|
