binutils-gdb/gdb/loongarch-tdep.h

48 lines
1.6 KiB
C
Raw Normal View History

/* Target-dependent header for the LoongArch architecture, for GDB.
Copyright (C) 2022-2024 Free Software Foundation, Inc.
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
the Free Software Foundation; either version 3 of the License, or
(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
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#ifndef LOONGARCH_TDEP_H
#define LOONGARCH_TDEP_H
#include "gdbarch.h"
#include "arch/loongarch.h"
#include "regset.h"
#include "elf/loongarch.h"
#include "opcode/loongarch.h"
/* Register set definitions. */
extern const struct regset loongarch_gregset;
extern const struct regset loongarch_fpregset;
extern const struct regset loongarch_lsxregset;
extern const struct regset loongarch_lasxregset;
extern const struct regset loongarch_lbtregset;
/* Target-dependent structure in gdbarch. */
struct loongarch_gdbarch_tdep : gdbarch_tdep_base
{
/* Features about the abi that impact how the gdbarch is configured. */
struct loongarch_gdbarch_features abi_features;
/* Return the expected next PC if FRAME is stopped at a syscall instruction. */
gdb: pass frames as `const frame_info_ptr &` We currently pass frames to function by value, as `frame_info_ptr`. This is somewhat expensive: - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass by value - the constructors and destructor link/unlink the object in the global `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so it's not so bad: it's just assigning a few points, there's no memory allocation as if it was `std::list`, but still it's useless to do that over and over. As suggested by Tom Tromey, change many function signatures to accept `const frame_info_ptr &` instead of `frame_info_ptr`. Some functions reassign their `frame_info_ptr` parameter, like: void the_func (frame_info_ptr frame) { for (; frame != nullptr; frame = get_prev_frame (frame)) { ... } } I wondered what to do about them, do I leave them as-is or change them (and need to introduce a separate local variable that can be re-assigned). I opted for the later for consistency. It might not be clear why some functions take `const frame_info_ptr &` while others take `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because it did re-assign its parameter, I doubt that we would think to change it to `const frame_info_ptr &` should the implementation change such that it doesn't need to take `frame_info_ptr` anymore. It seems better to have a simple rule and apply it everywhere. Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-20 02:07:47 +08:00
CORE_ADDR (*syscall_next_pc) (const frame_info_ptr &frame) = nullptr;
};
#endif /* LOONGARCH_TDEP_H */