On Sunday 22 July 2001 11:03 pm, Matt Thomas wrote:
> Are there any ABI changes that should be made as we switch to ELF?
>
> Bigger jmp_buf?
> any additional routines in libarm32?  Should that be renamed libarm?
> Do those routines do the right thing on arm26?
>
> 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.

I have to agree.  However I think the only userland place that it is actually 
needed is in libkvm (note I can't confirm this though), where is accesses a 
struct user, which happens to have pcb inside it.  I've been thinking on this 
and pondering if we could have something like:
2 extra syscalls, one gives the size of user, the other gives the offset of 
the pstats structure inside it.

libkvm finds out this information, allocates a buffer, does the kread of 
user, we then take the offset and set a pointer to point at it, that way we 
never have to care about the size of user, or the pcb (actually long term it 
means that we can change the size of pcb, and user without blowing up old 
libkvms :)

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

Add in a potential vfp and you're looking at 3 fp mechanisms, I suppose they 
could be merged into a union (only 1 of them is actually active at anyone 
time)

Chris