Re: gcc bug causes parted to write bad GPT entries

[Richard Hirst]

On Sat, Mar 16, 2002 at 12:01:17PM +1100, Andrew Clausen wrote:
> Anyway, I don't trust compilers, unless some language lawyer can
> prove that it will always work without ((packed)).

Well, I could put ((packed)) if gcc was 3.1 or better, assuming my tests
are successful.

> BTW, what is the bug exactly?

Consider the following code; if you look at the object for it you'll
see two items in .rodata, the string "dingdong" which takes 9 bytes, and
the 16 byte guid.  As the guid is packed, gcc lays down code to access
it at .rodata+9 (rather than +12 to align the uint32_t).  However, if
you then dump the .rodata section you'll see that the guid is actually
stored at .rodata+12 anyway.  Bugs are filed with the gcc folks, who
told me it was fixed in 3.1.  More background can be found in this
thread:

https://external-lists.vasoftware.com/archives//linux-ia64/2002-March/003158.html

If I remove ((packed)) then gcc adds a .align 4 before the guid data,
and generates code appropriately.

Richard


----------------------------------- cut ----------------------------------
typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;

typedef struct {
        uint32_t time_low;
        uint16_t time_mid;
        uint16_t time_hi_and_version;
        uint8_t  clock_seq_hi_and_reserved;
        uint8_t  clock_seq_low;
        uint8_t  node[6];
} __attribute__ ((packed)) efi_guid_t;

#define PARTITION_BASIC_DATA_GUID \
    ((efi_guid_t) { 0xEBD0A0A2, 0xB9E5, 0x4433, 0x87, 0xC0, { 0x68, 0xB6, 0xB7, 
0x26, 0x99, 0xC7 }})

void
bar (char **p)
{
        *p = "dingdong";
}

void
foo (efi_guid_t *g)
{
        *g = PARTITION_BASIC_DATA_GUID;
}

int
main (int argc, char **argv)
{
        efi_guid_t g;
        char *p;

        bar(&p);
        foo(&g);

        return 0;
}
----------------------------------- cut ----------------------------------