> Are there any ABI changes that should be made as we switch to ELF?
>
> Bigger jmp_buf?
Yep, must leave space for VFP call-saved registers (at least 8 Doubles).
May need space for the VFP status register (not sure if this needs to be
restored on a longjmp).
> any additional routines in libarm32? Should that be renamed libarm?
> Do those routines do the right thing on arm26?
In order to make trampolines work correctly, the compiler really needs to
make use of the cache synchronization function. Having it as a function
in libarm is a pain, since it means that either the compiler must emit the
SWI call directly, or libarm must be linked into every program on the
off-chance that it might use trampolines. How about having
__arm_sync_icach() (note preceeding underscores) in libc? It could be
exactly the same as the libarm version.
> One of the other issues is I want to merge the arm26 and arm32
> pcb.h files. However they are quite different. There are two ways
> of doing this. 1) is to have a struct pcb_arm32 and struct pcb_arm26
> and make struct pcb look like:
>
> struct pcb {
> int pcb_flags;
> #define PCB_FMT26 0x0002
> struct trapframe *pcb_tf;
> union {
> struct pcb_arm32 u_32;
> struct pcb_arm26 u_26;
> } pcb_u;
> };
>
> followed by a lot of defines like
> #define pcb_XX pcb_u.u_32.pcb32_XX
>
> But that's ugly.
>
> Even better would be to get them shared completely. But since they
> are drastically different, that might be difficult. arm26 seems to
> use its own version of fp_state_t called fpframe. arm32 uses
> fpe_sp_state_t. Both have different switch frames.
>
> Comments?
How many user programs need this information? Is it just the debugger?
If so, would it be better to insist that /proc be mounted and use GDB's
/proc interface? Then it wouldn't matter so much if the details of
implementation were different, since /proc would always present the same
abstraction.
R.