| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
|
|
Remove the macro, replace all uses with calls to type::length.
Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
|
|
Remove the macro, replace all uses by calls to type::target_type.
Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
|
|
According to LoongArch ELF ABI specification [1], variadic arguments
are passed in GARs in the same manner as named arguments. And after
a variadic argument has been passed on the stack, all future arguments
will also be passed on the stack, i.e., the last argument register may
be left unused due to the aligned register pair rule. long double data
tpye is passed in an aligned GAR pair, the first register in the pair
is even-numbered.
[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The current implementation of the fcc register is referenced to the
user_fp_state structure of the kernel uapi [1].
struct user_fp_state {
uint64_t fpr[32];
uint64_t fcc;
uint32_t fcsr;
};
But it is mistakenly defined as a 64-bit fputype register, resulting
in a confusing output of "info register".
(gdb) info register
...
fcc {f = 0x0, d = 0x0} {f = 0, d = 0}
...
According to "Condition Flag Register" in "LoongArch Reference Manual"
[2], there are 8 condition flag registers of size 1. Use 8 registers of
uint8 to make it easier for users to view the fcc register groups.
(gdb) info register
...
fcc0 0x1 1
fcc1 0x0 0
fcc2 0x0 0
fcc3 0x0 0
fcc4 0x0 0
fcc5 0x0 0
fcc6 0x0 0
fcc7 0x0 0
...
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h
[2] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_condition_flag_register
Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
According to LoongArch ELF ABI specification [1], handle the function
return value of various types.
[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_return_values
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Fix some code style issues suggested by Tom Tromey and Andrew Burgess,
thank you.
(1) Put an introductory comment to explain the purpose for some functions.
(2) Modify the the attribute code to make it portable.
(3) Remove globals and pass pointers to locals.
(4) Remove "*" in the subsequent comment lines.
(5) Put two spaces before "{" and "}".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
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.
|
|
This commit adds floating-point support for LoongArch gdb.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
"it’s" should be "it's".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
According to "Procedure Calling Convention" in "LoongArch ELF ABI
specification" [1], implement the push_dummy_call gdbarch method
as clear as possible.
[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_procedure_calling_convention
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The basic support for LoongArch has been merged into the upstream Linux
kernel since 5.19-rc1 on June 5, 2022. This commit adds orig_a0 which
is added into struct user_pt_regs [1] to match the upstream kernel, and
then the upstream GDB will work with the upstream kernel.
Note that orig_a0 was added into struct user_pt_regs in the development
cycle for merging LoongArch port into the upstream Linux kernel, so
earlier kernels (notably, the product kernel with version 4.19 used in
distros like UOS and Loongnix) don't have it. Inspect
arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure.
To build upstream GDB for a kernel lacking orig_a0, it's necessary to
revert this commit locally.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
When FRAME is at a syscall instruction, return the PC of the next
instruction to be executed.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This commit defines register numbers of various important registers,
we can use them directly in the related code, and also clean up some
code to make them more clear and readable.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/branch-to-self.exp"
there exist the following failed testcases:
FAIL: gdb.base/branch-to-self.exp: single-step: si (timeout)
FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: continue to breakpoint: continue to break (timeout)
FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: p counter (timeout)
Implement the software_single_step gdbarch method to decode the current
branch instruction and determine the address of the next instruction on
LoongArch to fix the above failed testcases.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The GDB style is to write 'if (readbuf != nullptr)', and the same for
writebuf.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/async.exp"
there exist the following failed testcases:
FAIL: gdb.base/async.exp: finish& (timeout)
FAIL: gdb.base/async.exp: jump& (timeout)
FAIL: gdb.base/async.exp: until& (timeout)
FAIL: gdb.base/async.exp: set exec-done-display off (GDB internal error)
we can see the following messages in gdb/testsuite/gdb.log:
finish&
Run till exit from #0 foo () at /home/loongson/gdb.git/gdb/testsuite/gdb.base/async.c:9
(gdb) /home/loongson/gdb.git/gdb/gdbarch.c:2646: internal-error: gdbarch_return_value: Assertion `gdbarch->return_value != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
In order to fix the above failed testcases, implement the return_value
gdbarch method on LoongArch.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
If can't determine prologue from the symbol table, need to examine
instructions. Implement loongarch_scan_prologue() to analyze the
function prologue from START_PC to LIMIT_PC, return the address of
the first instruction past the prologue.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
It is better to rename floatformats_ia64_quad to floatformats_ieee_quad
to reflect the reality, and then we can clean up the related code.
As Tom Tromey said [1]:
These files are maintained in gcc and then imported into the
binutils-gdb repository, so any changes to them will have to
be proposed there first.
the related changes have been merged into gcc master now [2], it is time
to do it for gdb.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b2dff6b2d9d6
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/align-c.exp"
there exist some failed testcases:
...
FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_float)
FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_double)
FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_long_double)
...
According to LoongArch ELF ABI specification [1], set the target data types
of floating-point to fix the above failed testcases.
[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This commit adds initial baremetal support for LoongArch.
Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn>
Signed-off-by: Qing zhang <zhangqing@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
