pragma pack(1) on struct contains object

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Steven Woody

    pragma pack(1) on struct contains object

    In our project, one used the following struct

    #pragma pack(1)
    struct Foo {
    uint8_t b1;
    uint8_t b2;
    uint8_t b3;
    std::vector<uin t8_t buf;
    ...
    };
    #pragma pack()

    this work on PC, but not on ARM target using a gcc/g++ cross
    compiler. The problem is, on ARM, after defined a variable of Foo
    and want to access a method of buf, such as

    Foo foo;
    foo.buf.resize( 100);

    the program will exit. I guss it's a segment failure.


    Can you experts explain for me the reason? I know, it is suspious
    that why this guy use pack(1) on this kind of struct, but we can just
    ignore it and focus on the underlying reason why the usage cause the
    failure.

    Thanks in advance.

    -
    narke

  • peter koch

    #2
    Re: pragma pack(1) on struct contains object

    On 12 Jul., 12:26, Steven Woody <narkewo...@gma il.comwrote:
    In our project, one used the following struct
    >
    #pragma pack(1)
    struct Foo {
      uint8_t   b1;
      uint8_t   b2;
      uint8_t   b3;
      std::vector<uin t8_t buf;
      ...};
    >
    #pragma pack()
    >
    this work on PC, but not on ARM target using a gcc/g++ cross
    compiler.  The problem is, on ARM, after defined a variable of  Foo
    and want to access a method of buf, such as
    >
        Foo foo;
        foo.buf.resize( 100);
    >
    the program will exit.  I guss it's a segment failure.
    >
    Can you experts explain for me the reason?  I know, it is  suspious
    that why this guy use pack(1) on this kind of struct, but we can just
    ignore it and focus on the underlying reason why the usage cause the
    failure.
    Because some processors require that certain types are properly
    aligned. So stop packing your structures: even on x86 architectures,
    packed structures (although allowed) cause the code to run much more
    slowly.

    /Peter

    Comment

    • Rolf Magnus

      #3
      Re: pragma pack(1) on struct contains object

      Steven Woody wrote:
      In our project, one used the following struct
      >
      #pragma pack(1)
      struct Foo {
      uint8_t b1;
      uint8_t b2;
      uint8_t b3;
      std::vector<uin t8_t buf;
      ...
      };
      #pragma pack()
      >
      this work on PC, but not on ARM target using a gcc/g++ cross
      compiler. The problem is, on ARM, after defined a variable of Foo
      and want to access a method of buf, such as
      >
      Foo foo;
      foo.buf.resize( 100);
      >
      the program will exit. I guss it's a segment failure.
      >
      >
      Can you experts explain for me the reason?
      Because you enforce mis-alingment. And while PCs can still access
      mis-algined data (though at reduced speed), an ARM CPU simply can't.
      I know, it is suspious that why this guy use pack(1) on this kind of
      struct, but we can just ignore it and focus on the underlying reason why
      the usage cause the failure.
      Well that reason is at the same time the reason why this looks suspicious,
      since it's also the reason why you shouldn't do that in the first place.


      Comment

      • Steven Woody

        #4
        Re: pragma pack(1) on struct contains object

        On Jul 13, 1:25 am, Rolf Magnus <ramag...@t-online.dewrote:
        Steven Woody wrote:
        In our project, one used the following struct
        >
        #pragma pack(1)
        struct Foo {
        uint8_t b1;
        uint8_t b2;
        uint8_t b3;
        std::vector<uin t8_t buf;
        ...
        };
        #pragma pack()
        >
        this work on PC, but not on ARM target using a gcc/g++ cross
        compiler. The problem is, on ARM, after defined a variable of Foo
        and want to access a method of buf, such as
        >
        Foo foo;
        foo.buf.resize( 100);
        >
        the program will exit. I guss it's a segment failure.
        >
        Can you experts explain for me the reason?
        >
        Because you enforce mis-alingment. And while PCs can still access
        mis-algined data (though at reduced speed), an ARM CPU simply can't.
        >
        I know, it is suspious that why this guy use pack(1) on this kind of
        struct, but we can just ignore it and focus on the underlying reason why
        the usage cause the failure.
        >
        Well that reason is at the same time the reason why this looks suspicious,
        since it's also the reason why you shouldn't do that in the first place.

        Could you explain? Thanks.

        And, I am thinking another question: whether using packing a struct is
        itself a bad notion at all. You know, we are writting a network
        program, other members in the team tends to define a structure for
        every kind of packet come in/out from/to the network, because there is
        no padding in packets in the form of byte-stream, so "#pragma pack(1)"
        or "__attribute__( (packed))" was used almost everywhere. I personally
        dont' prefer this method, I just do the packet parsing and framing in
        a character by character way, hence don't mapping packets to any in-
        memory structure. Do these two kind of programming style imply
        anything? What kind do you prefer?

        Thanks in advance.

        Comment

        • Ian Collins

          #5
          Re: pragma pack(1) on struct contains object

          Steven Woody wrote:
          >
          *Please* don't quote sigs
          >
          >
          In your previous post, I thing I don't fully understand the term 'mis-
          alignment':
          Most, if not all processors prefer types to be aligned to their natural
          boundary, say 4 bytes for an int. When an int value is not aligned on a
          4 byte boundary, the processor may require one or two extra bus cycles
          to read the value form memory.

          Some processors (Sparc for example) *require* types to be aligned to
          their natural boundary. They will generate a hardware trap it you
          attempt a misaligned access.

          --
          Ian Collins.

          Comment

          Working...