Mail Archives: djgpp/1993/05/25/05:57:50
We've spent a lot of time recently looking into why our cross-linker
(binutils 2.2 ld) generates executables that crash when we try to
stat. As a sanity check, I built the old ld that comes with djgpp on
an i386 Unix box and it allows me to cross-link successfully.
I've noticed two interesting differences between the behavior of the
binutils 2.2 ld and the one shipped with djgpp:
1) The binutils ld rounds etext up to the nearest 0x400000 byte
boundary, while the djgpp ld rounds it up to the nearest 0x1000 (page
size). I fixed this in the binutils ld, but it didn't solve my
problem.
2) The djgpp ld generates "V" symbol table entries for __CTOR_LIST__
and __DTOR_LIST__. The binutils ld doesn't. I pored over the
binutils ld code, and it looks like it can't generate this type of
symbol, although the appropriate macros are defined. I don't know
how important this is. Various binutils-2.2 utilities (e.g. nm)
abort() when run on files with "V" entries.
Here is an interesting discrepancy between the cross-linked program
and the same program linked with djgpp:
< == cross linked, > == djgpp:
< 00000000 A __DYNAMIC
11,16c6,7
< 004001c8 D ___CTOR_LIST__
< 00001170 t ___CTOR_LIST__
< 004001d4 D ___CTOR_LIST__$e
< 004001d4 D ___DTOR_LIST__
< 00001168 t ___DTOR_LIST__
< 004001e0 D ___DTOR_LIST__$e
---
> 004001d4 V ___CTOR_LIST__
> 004001c8 V ___DTOR_LIST__
Does this look glaringly wrong to anyone?
For reference, here is the C program that crashes go32 when
cross-linked, but works when it's not:
#include <sys/stat.h>
int
main (int argc, char *argv[])
{
struct stat s;
stat ("/", &s);
return 0;
}
I will send uuencoded copies of the good and/or the bad executables
to anyone who wants them.
-Mat
- Raw text -