Debian Bug report logs - #278459
bus errors and alignment traps on ARM systems

version graph

Package: smartmontools; Maintainer for smartmontools is Giuseppe Iuculano <iuculano@debian.org>; Source for smartmontools is src:smartmontools.

Reported by: armcc@lycos.com

Date: Wed, 27 Oct 2004 02:03:03 UTC

Severity: grave

Tags: patch

Found in version 5.32-1

Fixed in version smartmontools/5.32-2

Done: Guido Guenther <agx@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to armcc@lycos.com:
New Bug report received and forwarded. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: armcc@lycos.com
To: submit@bugs.debian.org
Subject: bus errors and alignment traps on ARM systems
Date: Tue, 26 Oct 2004 19:28:40 -0500
Package: smartmontools
Version: 5.32-1
Tags: patch

The struct definitions in atacmds.h do not use gcc syntax to
indicate structs which need to be packed. This results in
alignment traps, bus errors or incorrect results on cpus which
care about correct alignment of data types such as ARM.


diff -ruN smartmontools-5.32.orig/atacmds.h smartmontools-5.32/atacmds.h
--- smartmontools-5.32.orig/atacmds.h	2004-04-17 03:44:47.000000000 -0700
+++ smartmontools-5.32/atacmds.h	2004-10-26 17:12:32.000000000 -0700
@@ -108,7 +108,7 @@
   unsigned short word086;
   unsigned short csf_default;
   unsigned short words088_255[168];
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 /* ata_smart_attribute is the vendor specific in SFF-8035 spec */ 
@@ -122,7 +122,7 @@
   unsigned char worst;
   unsigned char raw[6];
   unsigned char reserv;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 // MACROS to interpret the flags bits in the previous structure.
@@ -189,7 +189,7 @@
   unsigned char reserved_375_385[11];
   unsigned char vendor_specific_386_510[125]; // Maxtor bytes 508-509 Attribute/Threshold Revision #
   unsigned char chksum;
-}; 
+} __attribute__ ((packed));
 #pragma pack()
 
 /* Maxtor, IBM: self-test failure checkpoint byte meaning:
@@ -207,7 +207,7 @@
   unsigned char id;
   unsigned char threshold;
   unsigned char reserved[10];
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 /* Format of Read SMART THreshold Command */
@@ -218,7 +218,7 @@
   struct ata_smart_threshold_entry thres_entries[NUMBER_ATA_SMART_ATTRIBUTES];
   unsigned char reserved[149];
   unsigned char chksum;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 
@@ -236,7 +236,7 @@
   unsigned char extended_error[19];
   unsigned char state;
   unsigned short timestamp;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 
@@ -252,7 +252,7 @@
   unsigned char drive_head;
   unsigned char commandreg;
   unsigned int timestamp;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 // Table 40 of T13/1321D Rev 1 spec (Error log data structure)
@@ -260,7 +260,7 @@
 struct ata_smart_errorlog_struct {
   struct ata_smart_errorlog_command_struct commands[5];
   struct ata_smart_errorlog_error_struct error_struct;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 // Table 39 of T13/1321D Rev 1 spec (SMART error log sector)
@@ -272,7 +272,7 @@
   unsigned short int ata_error_count;
   unsigned char reserved[57];
   unsigned char checksum;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 // Table 45 of T13/1321D Rev 1 spec (Self-test log descriptor entry)
@@ -284,7 +284,7 @@
   unsigned char selftestfailurecheckpoint;
   unsigned int lbafirstfailure;
   unsigned char vendorspecific[15];
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 // Table 44 of T13/1321D Rev 1 spec (Self-test log data structure)
@@ -296,7 +296,7 @@
   unsigned char mostrecenttest;
   unsigned char reserved[2];
   unsigned char chksum;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 // SMART LOG DIRECTORY Table 52 of T13/1532D Vol 1 Rev 1a
@@ -304,14 +304,14 @@
 struct ata_smart_log_entry {
   unsigned char numsectors;
   unsigned char reserved;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 #pragma pack(1)
 struct ata_smart_log_directory {
   unsigned short int logversion;
   struct ata_smart_log_entry entry[255];
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 // SMART SELECTIVE SELF-TEST LOG Table 61 of T13/1532D Volume 1
@@ -320,7 +320,7 @@
 struct test_span {
   uint64_t start;
   uint64_t end;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 #pragma pack(1)
@@ -336,7 +336,7 @@
   unsigned short     pendingtime;
   unsigned char      reserved2;
   unsigned char      checksum;
-};
+} __attribute__ ((packed));
 #pragma pack()
 
 #define SELECTIVE_FLAG_DOSCAN  (0x0002)



-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10




Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Bruce Allen <ballen@gravity.phys.uwm.edu>:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #10 received at 278459@bugs.debian.org (full text, mbox):

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: armcc@lycos.com, 278459@bugs.debian.org
Cc: Guido Guenther <agx@debian.org>
Subject: Re: Bug#278459: bus errors and alignment traps on ARM systems
Date: Wed, 27 Oct 2004 01:52:22 -0500 (CDT)
Thanks very much for this report.

I'm confused about something.  A long time ago we used to have the
__attribute__((packed)) in the various structure definitions, but
eliminated it in favor of the more portable

   #pragma pack(1)
   ...
   #pragma pack()

constructions which also worked across other compilers (sun cc, icc, etc).  
Under gcc/ARM, do the #pragma pack() statements NOT have the same effect
as __attribute__((packed))?  Is this a gcc bug?

Cheers,	
      Bruce

On Tue, 26 Oct 2004 armcc@lycos.com wrote:

> Package: smartmontools
> Version: 5.32-1
> Tags: patch
> 
> The struct definitions in atacmds.h do not use gcc syntax to
> indicate structs which need to be packed. This results in
> alignment traps, bus errors or incorrect results on cpus which
> care about correct alignment of data types such as ARM.
> 
> 
> diff -ruN smartmontools-5.32.orig/atacmds.h smartmontools-5.32/atacmds.h
> --- smartmontools-5.32.orig/atacmds.h	2004-04-17 03:44:47.000000000 -0700
> +++ smartmontools-5.32/atacmds.h	2004-10-26 17:12:32.000000000 -0700
> @@ -108,7 +108,7 @@
>    unsigned short word086;
>    unsigned short csf_default;
>    unsigned short words088_255[168];
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  /* ata_smart_attribute is the vendor specific in SFF-8035 spec */ 
> @@ -122,7 +122,7 @@
>    unsigned char worst;
>    unsigned char raw[6];
>    unsigned char reserv;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  // MACROS to interpret the flags bits in the previous structure.
> @@ -189,7 +189,7 @@
>    unsigned char reserved_375_385[11];
>    unsigned char vendor_specific_386_510[125]; // Maxtor bytes 508-509 Attribute/Threshold Revision #
>    unsigned char chksum;
> -}; 
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  /* Maxtor, IBM: self-test failure checkpoint byte meaning:
> @@ -207,7 +207,7 @@
>    unsigned char id;
>    unsigned char threshold;
>    unsigned char reserved[10];
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  /* Format of Read SMART THreshold Command */
> @@ -218,7 +218,7 @@
>    struct ata_smart_threshold_entry thres_entries[NUMBER_ATA_SMART_ATTRIBUTES];
>    unsigned char reserved[149];
>    unsigned char chksum;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  
> @@ -236,7 +236,7 @@
>    unsigned char extended_error[19];
>    unsigned char state;
>    unsigned short timestamp;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  
> @@ -252,7 +252,7 @@
>    unsigned char drive_head;
>    unsigned char commandreg;
>    unsigned int timestamp;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  // Table 40 of T13/1321D Rev 1 spec (Error log data structure)
> @@ -260,7 +260,7 @@
>  struct ata_smart_errorlog_struct {
>    struct ata_smart_errorlog_command_struct commands[5];
>    struct ata_smart_errorlog_error_struct error_struct;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  // Table 39 of T13/1321D Rev 1 spec (SMART error log sector)
> @@ -272,7 +272,7 @@
>    unsigned short int ata_error_count;
>    unsigned char reserved[57];
>    unsigned char checksum;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  // Table 45 of T13/1321D Rev 1 spec (Self-test log descriptor entry)
> @@ -284,7 +284,7 @@
>    unsigned char selftestfailurecheckpoint;
>    unsigned int lbafirstfailure;
>    unsigned char vendorspecific[15];
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  // Table 44 of T13/1321D Rev 1 spec (Self-test log data structure)
> @@ -296,7 +296,7 @@
>    unsigned char mostrecenttest;
>    unsigned char reserved[2];
>    unsigned char chksum;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  // SMART LOG DIRECTORY Table 52 of T13/1532D Vol 1 Rev 1a
> @@ -304,14 +304,14 @@
>  struct ata_smart_log_entry {
>    unsigned char numsectors;
>    unsigned char reserved;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  #pragma pack(1)
>  struct ata_smart_log_directory {
>    unsigned short int logversion;
>    struct ata_smart_log_entry entry[255];
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  // SMART SELECTIVE SELF-TEST LOG Table 61 of T13/1532D Volume 1
> @@ -320,7 +320,7 @@
>  struct test_span {
>    uint64_t start;
>    uint64_t end;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  #pragma pack(1)
> @@ -336,7 +336,7 @@
>    unsigned short     pendingtime;
>    unsigned char      reserved2;
>    unsigned char      checksum;
> -};
> +} __attribute__ ((packed));
>  #pragma pack()
>  
>  #define SELECTIVE_FLAG_DOSCAN  (0x0002)
> 
> 
> 
> -- 
> _______________________________________________
> Find what you are looking for with the Lycos Yellow Pages
> http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
> 
> 
> 
> 
> 




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Guido Guenther <agx@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #15 received at 278459@bugs.debian.org (full text, mbox):

From: Guido Guenther <agx@debian.org>
To: Bruce Allen <ballen@gravity.phys.uwm.edu>
Cc: armcc@lycos.com, 278459@bugs.debian.org
Subject: Re: Bug#278459: bus errors and alignment traps on ARM systems
Date: Wed, 27 Oct 2004 12:45:41 +0200
On Wed, Oct 27, 2004 at 01:52:22AM -0500, Bruce Allen wrote:
> Thanks very much for this report.
> 
> I'm confused about something.  A long time ago we used to have the
> __attribute__((packed)) in the various structure definitions, but
> eliminated it in favor of the more portable
> 
>    #pragma pack(1)
>    ...
>    #pragma pack()
> 
> constructions which also worked across other compilers (sun cc, icc, etc).  
> Under gcc/ARM, do the #pragma pack() statements NOT have the same effect
> as __attribute__((packed))?  Is this a gcc bug?
I'm surprised too, since it worked on sparc since ages. could this be a
compilere change?
 -- Guido



Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to armcc@lycos.com:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #20 received at 278459@bugs.debian.org (full text, mbox):

From: armcc@lycos.com
To: "Guido Guenther" <agx@debian.org>, "Bruce Allen" <ballen@gravity.phys.uwm.edu>
Cc: 278459@bugs.debian.org
Subject: Re: Bug#278459: bus errors and alignment traps on ARM systems
Date: Thu, 28 Oct 2004 00:22:54 -0500
#pragma pack(1) does seem to have _some_ effect on ARM gcc, but
it's slightly different to the effect of __attribute__ ((packed)).

The alignment traps come from the following code in
PrintSmartAttribWithThres()

      pout("%-28s",attributename);

      // printing line for each valid attribute
      type=ATTRIBUTE_FLAGS_PREFAILURE(disk->flags)?"Pre-fail":"Old_age";
      update=ATTRIBUTE_FLAGS_ONLINE(disk->flags)?"Always":"Offline";

when the value of 'disk->flags' is loaded from memory.


Case 1: struct ata_smart_attribute uses __attribute__ ((packed))

    eb98:	ebffee74 	bl	a570 <pout>
    eb9c:	e5d53004 	ldrb	r3, [r5, #4]
    eba0:	e5d51003 	ldrb	r1, [r5, #3]
    eba4:	e59f0114 	ldr	r0, [pc, #276]	; ecc0 <.text+0x5cb4>
    eba8:	e1811403 	orr	r1, r1, r3, lsl #8
    ebac:	e59fe110 	ldr	lr, [pc, #272]	; ecc4 <.text+0x5cb8>
    ebb0:	e3110001 	tst	r1, #1	; 0x1

ie the 16bit value of 'flags' is loaded with two separate ldrb (load byte)
instructions, then or'ed together. This version works fine.

(Note that the pointer in register r5 is derived from the pointer to
the struct ata_smart_values container struct rather than pointing to
the struct ata_smart_attribute directly, which is why the byte loads
are from offsets 3 and 4 rather than 1 and 2).


Case 2: struct ata_smart_attribute uses #pragma pack(1)

    eba0:	ebffee72 	bl	a570 <pout>
    eba4:	e5951002 	ldr	r1, [r5, #2]
    eba8:	e1a01401 	mov	r1, r1, lsl #8
    ebac:	e1a01821 	mov	r1, r1, lsr #16
    ebb0:	e59f0110 	ldr	r0, [pc, #272]	; ecc8 <.text+0x5cbc>
    ebb4:	e59fe110 	ldr	lr, [pc, #272]	; eccc <.text+0x5cc0>
    ebb8:	e3110001 	tst	r1, #1	; 0x1

ie the 16bit value of 'flags' is loaded with a single ldr (load 32bit)
instruction, then bits 8..23 are masked off with left and right shifts.
This is wrong and causes the alignment trap.


Case 3: struct ata_smart_attribute has no packing directives

    eb90:	ebffee76 	bl	a570 <pout>
    eb94:	e1d510b4 	ldrh	r1, [r5, #4]
    eb98:	e59f0108 	ldr	r0, [pc, #264]	; eca8 <.text+0x5c9c>
    eb9c:	e59fe108 	ldr	lr, [pc, #264]	; ecac <.text+0x5ca0>
    eba0:	e3110001 	tst	r1, #1	; 0x1
    eba4:	11a0e000 	movne	lr, r0

ie the 16bit value of 'flags' is loaded with a single ldrh (load 16bit),
but the offset is 4 bytes into the struct ata_smart_values which is wrong.
I didn't run this code, but it would certainly fail (although maybe by
giving incorrect output rather than an alignment trap).


Therefore, it looks like __attribute__ ((packed)) implies that the compiler
should not insert padding into the struct AND it should make no particular
assumptions about the alignment of the start of the struct.

#pragma pack(1) seems to imply the first restriction only (ie the compiler
still assumes that the start of a struct is 32bit aligned - which is the
norm for ARM). This seems to fail if a packed struct is contained within
another packed struct such that the inner struct does not begin on a 32bit
boundary ??

I tried the following simple test case:


#pragma pack(1)
struct a {
  unsigned char id;
  unsigned short flags;
};
#pragma pack(0)

#pragma pack(1)
struct b {
  unsigned short pad;
  struct a contained[2];
};
#pragma pack(0)

int foo (struct b *container)
{
  return container->contained->flags;
}


Which compiles and disassembles to:

00000000 <foo>:
   0:   e5900002        ldr     r0, [r0, #2]
   4:   e1a00400        mov     r0, r0, lsl #8
   8:   e1a00820        mov     r0, r0, lsr #16
   c:   e1a0f00e        mov     pc, lr

(gcc 3.3.4 and 3.4.2 both give the same result).

This would trigger an alignment fault, therefore it looks to me like a gcc bug... ??



-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10




Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Bruce Allen <ballen@gravity.phys.uwm.edu>:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #25 received at 278459@bugs.debian.org (full text, mbox):

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: 278459@bugs.debian.org, armcc@lycos.com
Cc: Smartmontools Mailing List <smartmontools-support@lists.sourceforge.net>
Subject: Re: [smartmontools-support]#pragma pack(1) doesn't work for gcc ??
Date: Thu, 28 Oct 2004 01:46:24 -0500 (CDT)
On Thu, 28 Oct 2004 armcc@lycos.com wrote:

> Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
> > 
> > I think that this is a gcc bug.
> > Could you please compile the stock code adding:
> > -Wunknown-pragmas
> > to CFLAGS and see if it complains under ARM?
> > 
> 
> -Wunknown-pragmas don't cause a warning. There's more
> information in the Debian bug report here:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278459

Thank you!

I reviewed this report and agree with the tentative conclusion that this
is a gcc bug.

If there is something that I can put into smartmontools as a workaround
until gcc gets fixed, I'd be very happy to include it.  Unfortunately the
__attribute__(packed) construction is not portable.  Could you either
propose a portable contruction that fixes the ARM problem or alternatively
submit a patch which protects this with some type of

#ifdef __GCC__ && __ARM__ /* warning: GUESSING syntax */

or something similar?

Cheers,
	Bruce





Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Guido Guenther <agx@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #30 received at 278459@bugs.debian.org (full text, mbox):

From: Guido Guenther <agx@debian.org>
To: armcc@lycos.com
Cc: Bruce Allen <ballen@gravity.phys.uwm.edu>, 278459@bugs.debian.org
Subject: Re: Bug#278459: bus errors and alignment traps on ARM systems
Date: Thu, 28 Oct 2004 09:05:29 +0200
Hi,
many, many thanks for your findings! I'm forwarding this to the debian
arm list now.
 -- Guido

On Thu, Oct 28, 2004 at 12:22:54AM -0500, armcc@lycos.com wrote:
> #pragma pack(1) does seem to have _some_ effect on ARM gcc, but
> it's slightly different to the effect of __attribute__ ((packed)).
> 
> The alignment traps come from the following code in
> PrintSmartAttribWithThres()
> 
>       pout("%-28s",attributename);
> 
>       // printing line for each valid attribute
>       type=ATTRIBUTE_FLAGS_PREFAILURE(disk->flags)?"Pre-fail":"Old_age";
>       update=ATTRIBUTE_FLAGS_ONLINE(disk->flags)?"Always":"Offline";
> 
> when the value of 'disk->flags' is loaded from memory.
> 
> 
> Case 1: struct ata_smart_attribute uses __attribute__ ((packed))
> 
>     eb98:	ebffee74 	bl	a570 <pout>
>     eb9c:	e5d53004 	ldrb	r3, [r5, #4]
>     eba0:	e5d51003 	ldrb	r1, [r5, #3]
>     eba4:	e59f0114 	ldr	r0, [pc, #276]	; ecc0 <.text+0x5cb4>
>     eba8:	e1811403 	orr	r1, r1, r3, lsl #8
>     ebac:	e59fe110 	ldr	lr, [pc, #272]	; ecc4 <.text+0x5cb8>
>     ebb0:	e3110001 	tst	r1, #1	; 0x1
> 
> ie the 16bit value of 'flags' is loaded with two separate ldrb (load byte)
> instructions, then or'ed together. This version works fine.
> 
> (Note that the pointer in register r5 is derived from the pointer to
> the struct ata_smart_values container struct rather than pointing to
> the struct ata_smart_attribute directly, which is why the byte loads
> are from offsets 3 and 4 rather than 1 and 2).
> 
> 
> Case 2: struct ata_smart_attribute uses #pragma pack(1)
> 
>     eba0:	ebffee72 	bl	a570 <pout>
>     eba4:	e5951002 	ldr	r1, [r5, #2]
>     eba8:	e1a01401 	mov	r1, r1, lsl #8
>     ebac:	e1a01821 	mov	r1, r1, lsr #16
>     ebb0:	e59f0110 	ldr	r0, [pc, #272]	; ecc8 <.text+0x5cbc>
>     ebb4:	e59fe110 	ldr	lr, [pc, #272]	; eccc <.text+0x5cc0>
>     ebb8:	e3110001 	tst	r1, #1	; 0x1
> 
> ie the 16bit value of 'flags' is loaded with a single ldr (load 32bit)
> instruction, then bits 8..23 are masked off with left and right shifts.
> This is wrong and causes the alignment trap.
> 
> 
> Case 3: struct ata_smart_attribute has no packing directives
> 
>     eb90:	ebffee76 	bl	a570 <pout>
>     eb94:	e1d510b4 	ldrh	r1, [r5, #4]
>     eb98:	e59f0108 	ldr	r0, [pc, #264]	; eca8 <.text+0x5c9c>
>     eb9c:	e59fe108 	ldr	lr, [pc, #264]	; ecac <.text+0x5ca0>
>     eba0:	e3110001 	tst	r1, #1	; 0x1
>     eba4:	11a0e000 	movne	lr, r0
> 
> ie the 16bit value of 'flags' is loaded with a single ldrh (load 16bit),
> but the offset is 4 bytes into the struct ata_smart_values which is wrong.
> I didn't run this code, but it would certainly fail (although maybe by
> giving incorrect output rather than an alignment trap).
> 
> 
> Therefore, it looks like __attribute__ ((packed)) implies that the compiler
> should not insert padding into the struct AND it should make no particular
> assumptions about the alignment of the start of the struct.
> 
> #pragma pack(1) seems to imply the first restriction only (ie the compiler
> still assumes that the start of a struct is 32bit aligned - which is the
> norm for ARM). This seems to fail if a packed struct is contained within
> another packed struct such that the inner struct does not begin on a 32bit
> boundary ??
> 
> I tried the following simple test case:
> 
> 
> #pragma pack(1)
> struct a {
>   unsigned char id;
>   unsigned short flags;
> };
> #pragma pack(0)
> 
> #pragma pack(1)
> struct b {
>   unsigned short pad;
>   struct a contained[2];
> };
> #pragma pack(0)
> 
> int foo (struct b *container)
> {
>   return container->contained->flags;
> }
> 
> 
> Which compiles and disassembles to:
> 
> 00000000 <foo>:
>    0:   e5900002        ldr     r0, [r0, #2]
>    4:   e1a00400        mov     r0, r0, lsl #8
>    8:   e1a00820        mov     r0, r0, lsr #16
>    c:   e1a0f00e        mov     pc, lr
> 
> (gcc 3.3.4 and 3.4.2 both give the same result).
> 
> This would trigger an alignment fault, therefore it looks to me like a gcc bug... ??
> 
> 
> 
> -- 
> _______________________________________________
> Find what you are looking for with the Lycos Yellow Pages
> http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Guido Guenther <agx@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #35 received at 278459@bugs.debian.org (full text, mbox):

From: Guido Guenther <agx@debian.org>
To: debian-arm@lists.debian.org
Cc: Bruce Allen <ballen@gravity.phys.uwm.edu>, 278459@bugs.debian.org, armcc@lycos.com
Subject: [armcc@lycos.com: Bug#278459: bus errors and alignment traps on ARM systems]
Date: Thu, 28 Oct 2004 09:10:00 +0200
Dear Arm Developers,
could someone please have a quick look at Bug #278459 which seems to be a
structure alignment problem when "#pragma pack" is being used instead of
__attribute__(packed). It be nice to know if this is a gcc problem or
intended behaviour.
Cheers,
 -- Guido



Severity set to `grave'. Request was from Guido Guenther <agx@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Guido Guenther <agx@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #42 received at 278459@bugs.debian.org (full text, mbox):

From: Guido Guenther <agx@debian.org>
To: Bruce Allen <ballen@gravity.phys.uwm.edu>, 278459@bugs.debian.org
Cc: armcc@lycos.com, Smartmontools Mailing List <smartmontools-support@lists.sourceforge.net>
Subject: Re: Bug#278459: [smartmontools-support]#pragma pack(1) doesn't work for gcc ??
Date: Thu, 28 Oct 2004 09:22:13 +0200
Hi,
Bruce, since Debian is about to release and the package is not
funtcional on arm at all at the moment, I'll change all #pragmas to
__attribute__(packed) for the debian package version 5.32-2. 
Gcc people suggest using #pragma whenever possible so we should probably
do that whenever we compile with gcc.
 -- Guido

On Thu, Oct 28, 2004 at 01:46:24AM -0500, Bruce Allen wrote:
> On Thu, 28 Oct 2004 armcc@lycos.com wrote:
> 
> > Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
> > > 
> > > I think that this is a gcc bug.
> > > Could you please compile the stock code adding:
> > > -Wunknown-pragmas
> > > to CFLAGS and see if it complains under ARM?
> > > 
> > 
> > -Wunknown-pragmas don't cause a warning. There's more
> > information in the Debian bug report here:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278459
> 
> Thank you!
> 
> I reviewed this report and agree with the tentative conclusion that this
> is a gcc bug.
> 
> If there is something that I can put into smartmontools as a workaround
> until gcc gets fixed, I'd be very happy to include it.  Unfortunately the
> __attribute__(packed) construction is not portable.  Could you either
> propose a portable contruction that fixes the ARM problem or alternatively
> submit a patch which protects this with some type of
> 
> #ifdef __GCC__ && __ARM__ /* warning: GUESSING syntax */
> 
> or something similar?
> 
> Cheers,
> 	Bruce
> 



Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Bruce Allen <ballen@gravity.phys.uwm.edu>:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #47 received at 278459@bugs.debian.org (full text, mbox):

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: Guido Guenther <agx@debian.org>, 278459@bugs.debian.org
Cc: armcc@lycos.com, Smartmontools Mailing List <smartmontools-support@lists.sourceforge.net>
Subject: Re: Bug#278459: [smartmontools-support]#pragma pack(1) doesn't work for gcc ??
Date: Thu, 28 Oct 2004 02:48:49 -0500 (CDT)
Hi Guido,

On Thu, 28 Oct 2004, Guido Guenther wrote:

> Hi,
> Bruce, since Debian is about to release and the package is not
> funtcional on arm at all at the moment, I'll change all #pragmas to
> __attribute__(packed) for the debian package version 5.32-2.

Fine.  I think that the original bug report had a patch that might not
have covered all #pragma pack(1), so be sure to grep the source for these.

> Gcc people suggest using #pragma whenever possible so we should probably
> do that whenever we compile with gcc.

I'm confused by this remark.  Currently in the code we DO use ONLY
#pragmas.  What do you want to do differently?

Cheers,
	Bruce


> On Thu, Oct 28, 2004 at 01:46:24AM -0500, Bruce Allen wrote:
> > On Thu, 28 Oct 2004 armcc@lycos.com wrote:
> > 
> > > Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
> > > > 
> > > > I think that this is a gcc bug.
> > > > Could you please compile the stock code adding:
> > > > -Wunknown-pragmas
> > > > to CFLAGS and see if it complains under ARM?
> > > > 
> > > 
> > > -Wunknown-pragmas don't cause a warning. There's more
> > > information in the Debian bug report here:
> > > 
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278459
> > 
> > Thank you!
> > 
> > I reviewed this report and agree with the tentative conclusion that this
> > is a gcc bug.
> > 
> > If there is something that I can put into smartmontools as a workaround
> > until gcc gets fixed, I'd be very happy to include it.  Unfortunately the
> > __attribute__(packed) construction is not portable.  Could you either
> > propose a portable contruction that fixes the ARM problem or alternatively
> > submit a patch which protects this with some type of
> > 
> > #ifdef __GCC__ && __ARM__ /* warning: GUESSING syntax */
> > 
> > or something similar?
> > 
> > Cheers,
> > 	Bruce
> > 
> 
> 
> 




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Guido Guenther <agx@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #52 received at 278459@bugs.debian.org (full text, mbox):

From: Guido Guenther <agx@debian.org>
To: Bruce Allen <ballen@gravity.phys.uwm.edu>
Cc: 278459@bugs.debian.org, armcc@lycos.com, Smartmontools Mailing List <smartmontools-support@lists.sourceforge.net>
Subject: Re: Bug#278459: [smartmontools-support]#pragma pack(1) doesn't work for gcc ??
Date: Thu, 28 Oct 2004 11:28:57 +0200
On Thu, Oct 28, 2004 at 02:48:49AM -0500, Bruce Allen wrote:
> > Gcc people suggest using #pragma whenever possible so we should probably
> > do that whenever we compile with gcc.
> 
> I'm confused by this remark.  Currently in the code we DO use ONLY
> #pragmas.  What do you want to do differently?
Typo. gcc info pages suggest to _not_ use #pragma. So we should use
__attribute__ ((packed)) on GCC systems.
 -- Guido



Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Bruce Allen <ballen@gravity.phys.uwm.edu>:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #57 received at 278459@bugs.debian.org (full text, mbox):

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: Guido Guenther <agx@debian.org>, 278459@bugs.debian.org
Cc: armcc@lycos.com, Smartmontools Mailing List <smartmontools-support@lists.sourceforge.net>
Subject: Re: Bug#278459: [smartmontools-support]#pragma pack(1) doesn't work for gcc ??
Date: Thu, 28 Oct 2004 04:48:06 -0500 (CDT)
> > > Gcc people suggest using #pragma whenever possible so we should probably
> > > do that whenever we compile with gcc.

> > I'm confused by this remark.  Currently in the code we DO use ONLY
> > #pragmas.  What do you want to do differently?

> Typo. gcc info pages suggest to _not_ use #pragma. So we should use
> __attribute__ ((packed)) on GCC systems.

I'd prefer that the gcc people fix their #pragma.  Otherwise the code is
less portable: we'd need gcc-specific conditionals in the source code.  
At the very least we need to support Sun cc and icc in addition to gcc.

Cheers,	
    Bruce




Reply sent to Guido Guenther <agx@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to armcc@lycos.com:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #62 received at 278459-close@bugs.debian.org (full text, mbox):

From: Guido Guenther <agx@debian.org>
To: 278459-close@bugs.debian.org
Subject: Bug#278459: fixed in smartmontools 5.32-2
Date: Thu, 28 Oct 2004 09:02:07 -0400
Source: smartmontools
Source-Version: 5.32-2

We believe that the bug you reported is fixed in the latest version of
smartmontools, which is due to be installed in the Debian FTP archive:

smartmontools_5.32-2.diff.gz
  to pool/main/s/smartmontools/smartmontools_5.32-2.diff.gz
smartmontools_5.32-2.dsc
  to pool/main/s/smartmontools/smartmontools_5.32-2.dsc
smartmontools_5.32-2_powerpc.deb
  to pool/main/s/smartmontools/smartmontools_5.32-2_powerpc.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 278459@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guido Guenther <agx@debian.org> (supplier of updated smartmontools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 28 Oct 2004 09:20:57 +0200
Source: smartmontools
Binary: smartmontools
Architecture: source powerpc
Version: 5.32-2
Distribution: unstable
Urgency: medium
Maintainer: Guido Guenther <agx@debian.org>
Changed-By: Guido Guenther <agx@debian.org>
Description: 
 smartmontools - control and monitor storage systems using S.M.A.R.T.
Closes: 262055 278459
Changes: 
 smartmontools (5.32-2) unstable; urgency=medium
 .
   * urgency medium since the sarge version is unusable on arm
   * use __attribute__((packed)) instead of #pragma(packed) since the later
     causes alignment problems on arm - based on a patch by armcc@lycos.com,
     many thanks! (Closes: #278459)
   * simplify /usr/share/bug/smartmontools a bit (Closes: #262055)
Files: 
 f679b16c99701310e8764013355c57ea 577 utils optional smartmontools_5.32-2.dsc
 edd5ac96ef9cbf76af9495ab5b4ec81c 20180 utils optional smartmontools_5.32-2.diff.gz
 31296d056e88640cfc9e5e83dab8e30f 228178 utils optional smartmontools_5.32-2_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBgOpin88szT8+ZCYRAid0AJwOEDSMCJk2Q4gxv3++nR/vkgOrVACdFwO0
6t+GQ1vhxNdnOy4W/k36dio=
=edpT
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to armcc@lycos.com:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #67 received at 278459@bugs.debian.org (full text, mbox):

From: armcc@lycos.com
To: 278459@bugs.debian.org
Subject: Re: Bug#278459 acknowledged by developer(Bug#278459: fixed in smartmontools 5.32-2)
Date: Thu, 28 Oct 2004 18:02:22 -0500
Thanks everyone for the fast response !!
5.32-2 is working fine for me now on ARM.

If only the util-linux maintainers were so efficient... fdisk
is broken on ARM in a similar way, but I don't even get a
response to the bug report, let alone a fix ;-(

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=268119

Andre
--
-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10




Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to John Gilmore <gnu@toad.com>:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #72 received at 278459@bugs.debian.org (full text, mbox):

From: John Gilmore <gnu@toad.com>
To: Bruce Allen <ballen@gravity.phys.uwm.edu>
Cc: Guido Guenther <agx@debian.org>, 278459@bugs.debian.org, armcc@lycos.com, Smartmontools Mailing List <smartmontools-support@lists.sourceforge.net>
Subject: Re: Bug#278459: [smartmontools-support]#pragma pack(1) doesn't work for gcc ??
Date: Sat, 30 Oct 2004 14:46:39 -0700
> I'd prefer that the gcc people fix their #pragma.  Otherwise the code is
> less portable: we'd need gcc-specific conditionals in the source code.  
> At the very least we need to support Sun cc and icc in addition to gcc.

"#pragma" is not portable, period.  "#pragma pack(1)" is a microsoft-ism.

If you want to write portable code, write code that doesn't depend on any
pragmas.  The usual way to do this is to build your structures with nothing
but chars and char arrays (unsigned or signed).  Write short stub routines
that translate these into the structs that you prefer to use.  This also
solves any byte-order problems as well as any alignment problems.  E.g. your
code to extract two unsigned chars into a big-endian short is:

  mystruct.myshort = (short)((extstruct.myshort[0]<<8) + extstruct.myshort[1])

For a little-endian short, it's:

  mystruct.myshort = (short)((extstruct.myshort[1]<<8) + extstruct.myshort[0])

This makes the code run on any byte order and any odd alignment.

The BFD library in the binutils does this.  We measured the performance
cost when we put it in.  It costs less than 1% of the CPU time.  And it
stays portable forever.

	John



Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Bruce Allen <ballen@gravity.phys.uwm.edu>:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #77 received at 278459@bugs.debian.org (full text, mbox):

From: Bruce Allen <ballen@gravity.phys.uwm.edu>
To: John Gilmore <gnu@toad.com>, 278459@bugs.debian.org
Cc: Guido Guenther <agx@debian.org>, armcc@lycos.com, Smartmontools Developers List <smartmontools-devel@lists.sourceforge.net>, Smartmontools Mailing List <smartmontools-support@lists.sourceforge.net>
Subject: Re: Bug#278459: [smartmontools-support]#pragma pack(1) doesn't work for gcc ??
Date: Sun, 31 Oct 2004 00:14:44 -0500 (CDT)
Hi John,

I agree: modifying our code so that it is 'packing independent' is
ultimately the best solution.  Doug Gilbert pointed this out a long time
ago and thanks to him the SCSI code is done this way, exactly as you
suggest.  We simply need to modify the routines within atacmds.c that call
smartcommandhandler() to populate the necessary structures 'by hand'.  Eg
in ataReadHDIdentity(int device, struct ata_identify_device *buf) for
example we do:
  int i;
  char *rawbuffer[512];
  smartcommandhandler(device, IDENTIFY, 0, rawbuffer);
  /* all ATA data is little endian */
  for (i=0; i<10; i++)
     buf->words000_009[i]=(short)(rawbuffer[2*i]+rawbuffer[2*i+1]<<8);
  ...

it's trivial to do and to test, but at the moment I haven't got the time
to do this.  There are about 15 calls to smartcommandhandler and most of
them will require about a dozen lines of population code as above.

If anyone submits a clean patch for this or checks code into CVS I'd be
happy to take it.  John, if you want to do this yourself I'd be happy to
give you CVS write access.

Cheers,	
    Bruce


On Sat, 30 Oct 2004, John Gilmore wrote:

> > I'd prefer that the gcc people fix their #pragma.  Otherwise the code is
> > less portable: we'd need gcc-specific conditionals in the source code.  
> > At the very least we need to support Sun cc and icc in addition to gcc.
> 
> "#pragma" is not portable, period.  "#pragma pack(1)" is a microsoft-ism.
> 
> If you want to write portable code, write code that doesn't depend on any
> pragmas.  The usual way to do this is to build your structures with nothing
> but chars and char arrays (unsigned or signed).  Write short stub routines
> that translate these into the structs that you prefer to use.  This also
> solves any byte-order problems as well as any alignment problems.  E.g. your
> code to extract two unsigned chars into a big-endian short is:
> 
>   mystruct.myshort = (short)((extstruct.myshort[0]<<8) + extstruct.myshort[1])
> 
> For a little-endian short, it's:
> 
>   mystruct.myshort = (short)((extstruct.myshort[1]<<8) + extstruct.myshort[0])
> 
> This makes the code run on any byte order and any odd alignment.
> 
> The BFD library in the binutils does this.  We measured the performance
> cost when we put it in.  It costs less than 1% of the CPU time.  And it
> stays portable forever.
> 
> 	John
> 
> 
> 




Information forwarded to debian-bugs-dist@lists.debian.org, Guido Guenther <agx@debian.org>:
Bug#278459; Package smartmontools. Full text and rfc822 format available.

Acknowledgement sent to Phil Blundell <pb@nexus.co.uk>:
Extra info received and forwarded to list. Copy sent to Guido Guenther <agx@debian.org>. Full text and rfc822 format available.

Message #82 received at 278459@bugs.debian.org (full text, mbox):

From: Phil Blundell <pb@nexus.co.uk>
To: Martin Michlmayr <tbm@cyrius.com>
Cc: agx@debian.org
Subject: Re: [agx@debian.org: Bug#278459: bus errors and alignment traps on ARM systems]
Date: Tue, 2 Nov 2004 17:59:09 +0000
I'll have a look.  Reading the note you forwarded, it does look like gcc
is doing the wrong thing.  You shouldn't ever see code like:

> >     eba4:   e5951002        ldr     r1, [r5, #2]
> >     eba8:   e1a01401        mov     r1, r1, lsl #8
> >     ebac:   e1a01821        mov     r1, r1, lsr #16

with any recent (last five years or so) Debian build of gcc.

p.

on Tue, Nov 02, 2004 at 05:33:14PM +0000, Martin Michlmayr wrote:
> Phil,
> 
> Do you have time to look at this bug?
> 
> ----- Forwarded message from Guido Guenther <agx@debian.org> -----
> 
> From: Guido Guenther <agx@debian.org>
> Subject: Bug#278459: bus errors and alignment traps on ARM systems
> Date: Thu, 28 Oct 2004 09:05:29 +0200
> To: armcc@lycos.com
> Cc: Bruce Allen <ballen@gravity.phys.uwm.edu>, 278459@bugs.debian.org
> User-Agent: Mutt/1.5.6i
> X-Debian-PR-Package: smartmontools
> 
> Hi,
> many, many thanks for your findings! I'm forwarding this to the debian
> arm list now.
>  -- Guido
> 
> On Thu, Oct 28, 2004 at 12:22:54AM -0500, armcc@lycos.com wrote:
> > #pragma pack(1) does seem to have _some_ effect on ARM gcc, but
> > it's slightly different to the effect of __attribute__ ((packed)).
> > 
> > The alignment traps come from the following code in
> > PrintSmartAttribWithThres()
> > 
> >       pout("%-28s",attributename);
> > 
> >       // printing line for each valid attribute
> >       type=ATTRIBUTE_FLAGS_PREFAILURE(disk->flags)?"Pre-fail":"Old_age";
> >       update=ATTRIBUTE_FLAGS_ONLINE(disk->flags)?"Always":"Offline";
> > 
> > when the value of 'disk->flags' is loaded from memory.
> > 
> > 
> > Case 1: struct ata_smart_attribute uses __attribute__ ((packed))
> > 
> >     eb98:	ebffee74 	bl	a570 <pout>
> >     eb9c:	e5d53004 	ldrb	r3, [r5, #4]
> >     eba0:	e5d51003 	ldrb	r1, [r5, #3]
> >     eba4:	e59f0114 	ldr	r0, [pc, #276]	; ecc0 <.text+0x5cb4>
> >     eba8:	e1811403 	orr	r1, r1, r3, lsl #8
> >     ebac:	e59fe110 	ldr	lr, [pc, #272]	; ecc4 <.text+0x5cb8>
> >     ebb0:	e3110001 	tst	r1, #1	; 0x1
> > 
> > ie the 16bit value of 'flags' is loaded with two separate ldrb (load byte)
> > instructions, then or'ed together. This version works fine.
> > 
> > (Note that the pointer in register r5 is derived from the pointer to
> > the struct ata_smart_values container struct rather than pointing to
> > the struct ata_smart_attribute directly, which is why the byte loads
> > are from offsets 3 and 4 rather than 1 and 2).
> > 
> > 
> > Case 2: struct ata_smart_attribute uses #pragma pack(1)
> > 
> >     eba0:	ebffee72 	bl	a570 <pout>
> >     eba4:	e5951002 	ldr	r1, [r5, #2]
> >     eba8:	e1a01401 	mov	r1, r1, lsl #8
> >     ebac:	e1a01821 	mov	r1, r1, lsr #16
> >     ebb0:	e59f0110 	ldr	r0, [pc, #272]	; ecc8 <.text+0x5cbc>
> >     ebb4:	e59fe110 	ldr	lr, [pc, #272]	; eccc <.text+0x5cc0>
> >     ebb8:	e3110001 	tst	r1, #1	; 0x1
> > 
> > ie the 16bit value of 'flags' is loaded with a single ldr (load 32bit)
> > instruction, then bits 8..23 are masked off with left and right shifts.
> > This is wrong and causes the alignment trap.
> > 
> > 
> > Case 3: struct ata_smart_attribute has no packing directives
> > 
> >     eb90:	ebffee76 	bl	a570 <pout>
> >     eb94:	e1d510b4 	ldrh	r1, [r5, #4]
> >     eb98:	e59f0108 	ldr	r0, [pc, #264]	; eca8 <.text+0x5c9c>
> >     eb9c:	e59fe108 	ldr	lr, [pc, #264]	; ecac <.text+0x5ca0>
> >     eba0:	e3110001 	tst	r1, #1	; 0x1
> >     eba4:	11a0e000 	movne	lr, r0
> > 
> > ie the 16bit value of 'flags' is loaded with a single ldrh (load 16bit),
> > but the offset is 4 bytes into the struct ata_smart_values which is wrong.
> > I didn't run this code, but it would certainly fail (although maybe by
> > giving incorrect output rather than an alignment trap).
> > 
> > 
> > Therefore, it looks like __attribute__ ((packed)) implies that the compiler
> > should not insert padding into the struct AND it should make no particular
> > assumptions about the alignment of the start of the struct.
> > 
> > #pragma pack(1) seems to imply the first restriction only (ie the compiler
> > still assumes that the start of a struct is 32bit aligned - which is the
> > norm for ARM). This seems to fail if a packed struct is contained within
> > another packed struct such that the inner struct does not begin on a 32bit
> > boundary ??
> > 
> > I tried the following simple test case:
> > 
> > 
> > #pragma pack(1)
> > struct a {
> >   unsigned char id;
> >   unsigned short flags;
> > };
> > #pragma pack(0)
> > 
> > #pragma pack(1)
> > struct b {
> >   unsigned short pad;
> >   struct a contained[2];
> > };
> > #pragma pack(0)
> > 
> > int foo (struct b *container)
> > {
> >   return container->contained->flags;
> > }
> > 
> > 
> > Which compiles and disassembles to:
> > 
> > 00000000 <foo>:
> >    0:   e5900002        ldr     r0, [r0, #2]
> >    4:   e1a00400        mov     r0, r0, lsl #8
> >    8:   e1a00820        mov     r0, r0, lsr #16
> >    c:   e1a0f00e        mov     pc, lr
> > 
> > (gcc 3.3.4 and 3.4.2 both give the same result).
> > 
> > This would trigger an alignment fault, therefore it looks to me like a gcc bug... ??
> > 
> > 
> > 
> > -- 
> > _______________________________________________
> > Find what you are looking for with the Lycos Yellow Pages
> > http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 
> ----- End forwarded message -----
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 11:26:38 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.