Mail Archives: djgpp-workers/2011/07/30/03:06:40
> Date: Fri, 29 Jul 2011 23:01:07 +0300
> From: Ozkan Sezer <sezeroz AT gmail DOT com>
>
> On Fri, Jul 29, 2011 at 6:32 PM, Ozkan Sezer <sezeroz AT gmail DOT com> wrote:
> > Hi all:
> >
> > dxegen segfaults when built as a 64 bit host tool in
> > dxe3gen.c:553 (write_dxe) most probably due to "long"
> > data type usage at many places (such as coff.h)
Can you provide more details about the context? Are you trying to run
dxegen _natively_ (as opposed to as a cross-compilation tool) on a
x86_64 platform? IOW, what is the purpose of this compilation?
> OK, here is a patch that seems to work for me (see attached 64.patch)
If this is just a replacement of integer types, then it's a largely
mechanical patch.
It is mostly okay, but I don't understand why you went so far and
deep, and changed also the types that don't need to be changed at all.
For example, neither `short' nor `int' have different size on any
known machine that can be ever supported by DJGPP, so why change them
at all? IOW, I would only change `long' to `int', and that's it. No
need for stdint.h and intNN_t stuff. Would that be enough?
> - fwrite(&relocs[i].r_vaddr, 1, sizeof(long), outf);
> + fwrite(&relocs[i].r_vaddr, 1, sizeof(int32_t), outf);
This (and other similar) issue are better solved by using the variable
in question, not its type. Like this:
fwrite(&relocs[i].r_vaddr, 1, sizeof(relocs[i].r_vaddr), outf);
Then the code will DTRT with no changes required even if the type of
the variable is changed.
- Raw text -