Mail Archives: djgpp/2012/01/01/19:00:37
Hi,
On Dec 25 2011, 6:49 pm, RayeR <gl DOT DOT DOT AT centrum DOT cz> wrote:
>
> e:/djgpp/bin/as.exe: dsputil.o: /68: reloc overflow: 0x15b32 > 0xffff
>
> btw dsputil.o is quite large (3,4MB) file, compiling taken some
> seconds maybe problem due to low memory?
>
> When experimenting I found that if I compile the problem file with -O2
> instead of -O3 it pass!
> So now it seems that GCC 4.6.2 generates some crippled code that AS
> cannot assemble?!
Okay, so we know that original COFF (and DJGPP) can't yet handle more
than 0xffff relocs.
Well, I grabbed your package from here (warning: 31 MB):
http://sourceforge.net/projects/ffmpeg-x264-dos/files/ffmpeg-x264-dos-26-11-2011.rar/download
I unpacked it and cross-compiled (this one file only!) atop PuppyLinux
with Ozkan's GCC 3.4.6 toolchain (as + ld 2.16.1). I didn't see any
reloc warnings, so I'm guessing it's something GCC 4.6.2 specific.
Granted, it is fairly large output, but definitely not 3.4 MB, only
800 kb. Perhaps latest Dwarf-3 or whatever or latest GCC 4.6.2 output
is more bloated than it used to be with older GCC 3.4.6 ??
-rw-r--r-- 1 root root 110618 2011-12-26 13:47 dsputil.c
-rw-r--r-- 1 root root 1484 2012-01-01 17:10 dsputil.d
-rw-r--r-- 1 root root 31890 2011-12-11 21:27 dsputil.h
-rw-r--r-- 1 root root 721274 2012-01-01 17:10 dsputil.i
-rw-r--r-- 1 root root 340295 2012-01-01 17:09 dsputil-nodebug.o
-rw-r--r-- 1 root root 853733 2012-01-01 16:57 dsputil.o
-rw-r--r-- 1 root root 56263 2011-12-11 21:27 dsputil_template.c
The "nodebug" is from "strip -d", so it still has relocs but no added
debug cruft. The .i is preprocessed ("gcc -E"), so that's basically
what we're dealing with when including all those 15+ headers
(right??). And this is indeed with -O3 (it ignored the pragma), though
I had to remove a few non-existent switches as FFMPEG apparently uses
a lot!
objdump -r dsputil.o | wc
14320 42925 501408
objdump -r dsputil-nodebug.o | wc
1266 3788 41956
Okay, so not exact by any means, but it's as close a reloc count as I
can guess (being a dummy, doh). Is there a better way without manually
reading the COFF headers?
Anyways, I don't think this helps explain much, but maybe it's a start.
- Raw text -