> 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.