This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[00/03] per-aspace target_gdbarch (+local gdbarch obsoletion?)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb-patches at sourceware dot org
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Sun, 10 Jan 2010 21:14:32 +0100
- Subject: [00/03] per-aspace target_gdbarch (+local gdbarch obsoletion?)
Hi Ulrich and all,
let's imaginge address_space contains its gdbarch now (it is [01/03]).
There is now gdbarch in bp_location since:
Re: [06/15] Per-breakpoint architecture support
http://sourceware.org/ml/gdb-patches/2009-07/msg00075.htmlw
so one can have an idea replacing bp_location->gdbarch by
bp_location->pspace->aspace->gdbarch. Still I think it is inappropriate now
as it would break compatibility with Cell/B.E. - its PPE and SPE code shares
the same aspace now while it needs different gdbarch for functions like
gdbarch_breakpoint_from_pc; Cell/B.E. GDB architecture was described at:
[rfc] [00/18] Cell multi-arch debugger
http://sourceware.org/ml/gdb-patches/2008-09/msg00134.html
% Adresses with most significant bit zero are PowerPC addresses. Addresses with
% most significant bit one are SPU addresses, and encode the context ID in the
% high 32-bit (except the MSB), and the local store address in the low 32-bit.
Now with multi-executable support checked-in I think SPE should be represented
as fully separate program_space with its own separate address_space. This
whole frame-specific gdbarch would become obsolete together with
get_current_gdbarch(). target_gdbarch tracking current_program_space
(=current inferior) would be enough.
I would be for this simplification as I find the current multi-gdbarch
everywhere execution difficult to think about while implementing new code.
Or do you think it is worth to support multi gdbarch in single address_spaces?
I can imagine wishes for 64bit code linking with proprietary 32bit libraries.
For Adobe Flash (before it was 64bit) it has been resolved by different
process/address-space via nspluginwrapper. Still technically the possibility
is left open in Linux kernel according to Roland McGrath (2009-09-18):
% there is a "32-bit-flavored task", but it's not really true that it has
% 32-bit registers. there is no 32-bit-only userland condition. any task can
% always ljmp to the 64-bit code segment and run 64-bit insns including
% a 64-bit syscall
This patchset is required for PIE but only in biarch (64bit debugger -> 32bit
inferior) or just for 32bit host built with --enable-64-bit-bfd mode.
Thanks,
Jan