2013-02-01 20:59:08 +00:00
|
|
|
/* Common target-dependent code for ppc64.
|
|
|
|
|
|
2024-01-12 15:30:44 +00:00
|
|
|
Copyright (C) 1986-2024 Free Software Foundation, Inc.
|
2013-02-01 20:59:08 +00: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
|
|
|
|
|
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 PPC64_TDEP_H
|
|
|
|
|
#define PPC64_TDEP_H
|
|
|
|
|
|
|
|
|
|
struct gdbarch;
|
2022-07-25 14:06:35 -03:00
|
|
|
class frame_info_ptr;
|
2013-02-01 20:59:08 +00:00
|
|
|
struct target_ops;
|
|
|
|
|
|
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-19 13:07:47 -05:00
|
|
|
extern CORE_ADDR ppc64_skip_trampoline_code (const frame_info_ptr &frame,
|
2013-02-01 20:59:08 +00:00
|
|
|
CORE_ADDR pc);
|
|
|
|
|
|
|
|
|
|
extern CORE_ADDR ppc64_convert_from_func_ptr_addr (struct gdbarch *gdbarch,
|
|
|
|
|
CORE_ADDR addr,
|
|
|
|
|
struct target_ops *targ);
|
|
|
|
|
|
2013-02-22 23:24:24 +00:00
|
|
|
extern void ppc64_elf_make_msymbol_special (asymbol *,
|
|
|
|
|
struct minimal_symbol *);
|
2013-02-01 20:59:08 +00:00
|
|
|
#endif /* PPC64_TDEP_H */
|