Re: gcc bug causes parted to write bad GPT entries

[Richard Hirst]

On Mon, Mar 18, 2002 at 10:56:05PM +0000, Richard Hirst wrote:
> On Mon, Mar 18, 2002 at 04:47:36PM -0600, address@hidden wrote:
> > It might make sense to declare that data in the structures is always LE, and
> > drop the conversion between on-disk and memory.
> > Then, on structure access, use macros that on LE just return the structure
> > member, and on BE, swab on access, but the data in the structures never
> > changes.  Then, none of this "what format is it in" business.  It's always
> > LE, and to access the structure members, you've got to use macros.
> > 
> > Thoughts?
> 
> ... and swap round calls to libuuid, as your patch from a while back
> did.  That makes sense to me, I'll look through the code with that in
> mind tomorrow and see if anything else jumps out.

That works quite well, and as an added bonus, the size of gpt_disk.o
drops from 53K to 46K on ia64, -Os.

On the downside, on big-endian hppa, the size increases from 37K to 52K.
(just fixing the definition of PED_LE64_TO_CPU() made it grow by nearly
4K, and we do a lot more inline swapping now).

I'll assume that we are going to take this approach, and post a new
patch shortly.  I'm still of the view that we should treat the GUIDs as
raw 16 byte blobs.  The structure of them is now only used inside your
swap_uuid_and_efi_guid() function, so that would have to be implemented
some other way.

BTW, with my changes parted GPT support actually works on big-endian; I
partitioned a disk on ia64 and read the table on hppa.  No kernel
support, so I couldn't actually use it - but the kernel code has the
same 'crc after byteswap' problem anyway (as does debian boot-floppies,
as I lifted the parted code before I noticed the problem).

Richard