Hello Sergey, That's a good bit of sleuthing. A couple of questions immediately come to mind:
- Why does gcc and pcc take 4 as their alignment? Why do we take 32? - Does this have any performance impact? - Is there a reason you are implementing this with #ifdef? Might we use a preprocessor value (i.e. TCC_DEFAULT_ALIGNMENT) and #define that in architecture-specific header files instead? Thanks! David On Wed, Apr 20, 2016 at 11:49 AM, Sergey Korshunoff <sey...@gmail.com> wrote: > > Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o > with 0x04. > > This helped. > > diff --git a/libtcc.c b/libtcc.c > index 5aebd32..a8e109c 100644 > --- a/libtcc.c > +++ b/libtcc.c > @@ -514,7 +514,11 @@ ST_FUNC Section *new_section(TCCState *s1, const > char *name, int sh_type, int sh > sec->sh_addralign = 1; > break; > default: > + #ifdef TCC_TARGET_I386 > + sec->sh_addralign = 4; /* gcc/pcc default alignment for i386 */ > + #else > sec->sh_addralign = 32; /* default conservative alignment */ > + #endif > break; > } > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
