[Openmcl-devel] Release co, update, build - again...

[Jon S. Anthony]

On Sat, 2009-10-24 at 14:50 -0600, Gary Byers wrote:
> The general release scenario is something like:

Thanks for rehashing this yet again - basically it matches what I
thought.


> In general, what you were trying to do here (REBUILD-CCL :FULL T) is
> correct.  The error(s) have to do with the fact that header files on
> your system describe a low-level data structure as having different
> fields than we expect them to.  (I believe that the file in question
> is /usr/include/asm/ldt.h and structure in question is called 'user_desc';
> we expect it to look like:
> 
> struct user_desc {
>  	unsigned int  entry_number;
>  	unsigned int  base_addr;
>  	unsigned int  limit;
>  	unsigned int  seg_32bit:1;
>  	unsigned int  contents:2;
>  	unsigned int  read_exec_only:1;
>  	unsigned int  limit_in_pages:1;
>  	unsigned int  seg_not_present:1;
>  	unsigned int  useable:1;
> #ifdef __x86_64__
>  	unsigned int  lm:1;
> #endif
> };
> 
> and I'd guess that your version of that file describes the structure
> as having similar fields (IIRC, the layout of the structure is largely
> or entirely dictated by the x86 hardware) but refers to those fields
> with different names.

OK, this is FC5 (only about 2 1/2 years ago...), which may be (somewhat
surprisingly to me) too old.  The actual situation is rather dumber than
you indicate.  The ldt.h file is there.  The fields are all there and
all named exactly the same, but the structure is named modify_ldt_ldt_s.
Also, the base_addr field is unsigned long (though on 32 bits, I think
that is the same as unsigned int):

typedef struct modify_ldt_ldt_s {
	unsigned int  entry_number;
	unsigned long base_addr;
	unsigned int  limit;
	unsigned int  seg_32bit:1;
	unsigned int  contents:2;
	unsigned int  read_exec_only:1;
	unsigned int  limit_in_pages:1;
	unsigned int  seg_not_present:1;
	unsigned int  useable:1;
} modify_ldt_t;

It gets even more ridiculous.  user_desc appears, thought with a
slightly different name, in /usr/include/valgrind/vki-x86-linux.h (and
there are other platform specific files for this including PPC32, AMD64)
and is named vki_user_desc and then, probably to ensure the greatest
likely hood of confusion and failure, they also rename this to
vki_modify_ldt_t:

/* [[Nb: This is the structure passed to the modify_ldt syscall.  Just
so as
   to confuse and annoy everyone, this is _not_ the same as an
   VgLdtEntry and has to be translated into such.  The logic for doing
   so, in vg_ldt.c, is copied from the kernel sources.]] */
struct vki_user_desc {
	unsigned int  entry_number;
	unsigned long base_addr;
	unsigned int  limit;
	unsigned int  seg_32bit:1;
	unsigned int  contents:2;
	unsigned int  read_exec_only:1;
	unsigned int  limit_in_pages:1;
	unsigned int  seg_not_present:1;
	unsigned int  useable:1;
        // [[Nb: this field is not in the kernel sources, but it has
always
        // been in the Valgrind sources so I will keep it there in case
it's
        // important... this is an x86-defined data structure so who
        // knows;  maybe it's important to set this field to zero at
some
        // point.  --njn]]
	unsigned int  reserved:25;
};

// [[Nb: for our convenience within Valgrind, use a more specific name]]
typedef struct vki_user_desc vki_modify_ldt_t;

Go figure.  I suppose I should consider myself lucky that all this
nonsense seems to work (system has always seemed to be ok) at all.

I would guess that if I simply included your version into the ldt.h
file, it would "just work".  Then again, is there really any need to
recompile the kernel anyway???

/Jon