Any C compiler with the option to space out variables?

Discussion in 'C Programming' started by mathog, Apr 17, 2013.

  1. mathog

    mathog Guest

    I have run into one of those horrible bugs where the placement of
    print statements affects a calculation. These always come down to
    memory access issues or uninitialized variables, and this one is giving
    me conniptions. The code does not generate any compiler warnings with
    -Wall, nor any errors that gdb or Valgrind will flag, and adding range
    check code before every array access did not show any out of range
    memory accesses. The next step is to pull the code out of the larger
    program and test it separately, where perhaps changing optimization
    switches will let valgrind see something.

    This did bring up an interesting point though. Valgrind will say when a
    program accesses uninitialized memory or unallocated memory.
    Neither are happening here, so the memory error is probably of
    the type where a memory access goes to the wrong place, but there is a
    valid variable there. In order to find this one would need a way to
    move the memory which is used around, and especially to space it out,
    such that something like:

    int a,b,c; /* 4 byte integers */
    double d; /* 8 byte doubles */

    which is normally stored like:

    a 0-3
    b 4-7
    c 8-11
    d 12-19

    is instead stored spaced out like:

    - 0-16
    a 16-19
    - 20-31
    b 32-35
    - 36-47
    c 48-51
    - 52-55
    d 60-67
    - 68-71
    - 72-87

    A 32 or 64 byte space might be even better. If laid out in that manner,
    with uninitialized, unused memory between the variables, valgrind might
    find the problem.

    Are there any compilers that have a switch that will induce this sort of
    intentionally unpacked memory organization?

    (Manually inserting dummy variables in all those positions might work,
    although it would be a painful editing exercise, but more likely the
    compiler would warn about them and then optimize those variables
    out of existence.)

    Thanks,

    David Mathog
     
    mathog, Apr 17, 2013
    #1
    1. Advertising

  2. mathog

    mathog Guest

    mathog wrote:
    > The next step is to pull the code out of the larger
    > program and test it separately, where perhaps changing optimization
    > switches will let valgrind see something.


    Where it works perfectly with all levels of optimization tested, with or
    without the extra printf() statements. So no way to duplicate the
    problem with the simpler test case.

    This is going to be a long day.

    David Mathog
     
    mathog, Apr 17, 2013
    #2
    1. Advertising

  3. mathog

    Eric Sosman Guest

    On 4/17/2013 12:09 PM, mathog wrote:
    > I have run into one of those horrible bugs where the placement of
    > print statements affects a calculation. These always come down to
    > memory access issues or uninitialized variables, and this one is giving
    > me conniptions. The code does not generate any compiler warnings with
    > -Wall, nor any errors that gdb or Valgrind will flag, and adding range
    > check code before every array access did not show any out of range
    > memory accesses. The next step is to pull the code out of the larger
    > program and test it separately, where perhaps changing optimization
    > switches will let valgrind see something.
    >
    > This did bring up an interesting point though. Valgrind will say when a
    > program accesses uninitialized memory or unallocated memory.
    > Neither are happening here, so the memory error is probably of
    > the type where a memory access goes to the wrong place, but there is a
    > valid variable there. In order to find this one would need a way to
    > move the memory which is used around, and especially to space it out,
    > such that something like:
    >
    > int a,b,c; /* 4 byte integers */
    > double d; /* 8 byte doubles */
    >
    > which is normally stored like:
    >
    > a 0-3
    > b 4-7
    > c 8-11
    > d 12-19
    >
    > is instead stored spaced out like:
    >
    > - 0-16
    > a 16-19
    > - 20-31
    > b 32-35
    > - 36-47
    > c 48-51
    > - 52-55
    > d 60-67
    > - 68-71
    > - 72-87
    >
    > A 32 or 64 byte space might be even better. If laid out in that manner,
    > with uninitialized, unused memory between the variables, valgrind might
    > find the problem.
    >
    > Are there any compilers that have a switch that will induce this sort of
    > intentionally unpacked memory organization?
    >
    > (Manually inserting dummy variables in all those positions might work,
    > although it would be a painful editing exercise, but more likely the
    > compiler would warn about them and then optimize those variables
    > out of existence.)


    Compilers with such options may exist, although I don't
    recall encountering one. If you resort to manual insertion,
    there's a more reliable technique than just tossing variables
    in and hoping the compiler (1) puts them where you want and
    (2) doesn't optimize them away:

    typedef char Spacer[16];
    struct {
    Spacer x1;
    int a;
    Spaces x2;
    int b;
    Spacer x3;
    int c;
    Spacer x4;
    double d;
    Spacer x5;
    } vars;
    #define a vars.a
    #define b vars.b
    #define c vars.c
    #define d vars.d

    Alternatively,

    struct {
    Spacer x1;
    int value;
    Spacer x2;
    } x_a;
    #define a x_a.value
    // ... and so on

    An editor with mild programmability and macro prowess might be
    able to handle the latter form fairly painlessly.

    --
    Eric Sosman
    d
     
    Eric Sosman, Apr 17, 2013
    #3
  4. mathog

    Rox Guest

    maybe you should double check your print first.
    without strong type check, printf maybe work unusual in some circumstanes
     
    Rox, Apr 18, 2013
    #4
  5. mathog

    Walter Banks Guest

    Eric Sosman wrote:

    > On 4/17/2013 12:09 PM, mathog wrote:
    > > I have run into one of those horrible bugs where the placement of
    > > print statements affects a calculation. These always come down to
    > > memory access issues or uninitialized variables, and this one is giving
    > > me conniptions. The code does not generate any compiler warnings with
    > > -Wall, nor any errors that gdb or Valgrind will flag, and adding range
    > > check code before every array access did not show any out of range
    > > memory accesses. The next step is to pull the code out of the larger
    > > program and test it separately, where perhaps changing optimization
    > > switches will let valgrind see something.
    > >
    > > This did bring up an interesting point though. Valgrind will say when a
    > > program accesses uninitialized memory or unallocated memory.
    > > Neither are happening here, so the memory error is probably of
    > > the type where a memory access goes to the wrong place, but there is a
    > > valid variable there. In order to find this one would need a way to
    > > move the memory which is used around, and especially to space it out,
    > > such that something like:
    > >
    > > int a,b,c; /* 4 byte integers */
    > > double d; /* 8 byte doubles */
    > >
    > > which is normally stored like:
    > >
    > > a 0-3
    > > b 4-7
    > > c 8-11
    > > d 12-19
    > >
    > > is instead stored spaced out like:
    > >
    > > - 0-16
    > > a 16-19
    > > - 20-31
    > > b 32-35
    > > - 36-47
    > > c 48-51
    > > - 52-55
    > > d 60-67
    > > - 68-71
    > > - 72-87
    > >
    > > A 32 or 64 byte space might be even better. If laid out in that manner,
    > > with uninitialized, unused memory between the variables, valgrind might
    > > find the problem.
    > >
    > > Are there any compilers that have a switch that will induce this sort of
    > > intentionally unpacked memory organization?
    > >
    > > (Manually inserting dummy variables in all those positions might work,
    > > although it would be a painful editing exercise, but more likely the
    > > compiler would warn about them and then optimize those variables
    > > out of existence.)

    >
    > Compilers with such options may exist, although I don't
    > recall encountering one. If you resort to manual insertion,
    > there's a more reliable technique than just tossing variables
    > in and hoping the compiler (1) puts them where you want and
    > (2) doesn't optimize them away:
    >
    > typedef char Spacer[16];
    > struct {
    > Spacer x1;
    > int a;
    > Spaces x2;
    > int b;
    > Spacer x3;
    > int c;
    > Spacer x4;
    > double d;
    > Spacer x5;
    > } vars;
    > #define a vars.a
    > #define b vars.b
    > #define c vars.c
    > #define d vars.d
    >
    > Alternatively,
    >
    > struct {
    > Spacer x1;
    > int value;
    > Spacer x2;
    > } x_a;
    > #define a x_a.value
    > // ... and so on
    >
    > An editor with mild programmability and macro prowess might be
    > able to handle the latter form fairly painlessly.


    Quite a few C compilers including ours has the ability to place
    variables at specific locations.

    Eric's suggestion to create a struct is a good one to force
    any C compiler to put gaps between variables.

    Walter Banks
    Byte Craft Limited
     
    Walter Banks, Apr 24, 2013
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shuo Xiang

    Stack space, global space, heap space

    Shuo Xiang, Jul 9, 2003, in forum: C Programming
    Replies:
    10
    Views:
    2,980
    Bryan Bullard
    Jul 11, 2003
  2. Christian Seberino
    Replies:
    21
    Views:
    1,801
    Stephen Horne
    Oct 27, 2003
  3. Ian Bicking
    Replies:
    2
    Views:
    1,107
    Steve Lamb
    Oct 23, 2003
  4. Ian Bicking
    Replies:
    2
    Views:
    784
    Michael Hudson
    Oct 24, 2003
  5. Ben C
    Replies:
    6
    Views:
    2,250
    Leif K-Brooks
    Jan 28, 2007
Loading...

Share This Page