This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]