Mail Archives: djgpp/2008/03/28/15:30:13
Hi,
On Mar 28, 3:44 am, Robert Riebisch <Robert DOT Riebi DOT DOT DOT AT arcor DOT de> wrote:
> Rugxulo wrote:
> > Well, I've been using GCC 3.44 (and BNU2161B.ZIP) on my old P166
> > (DR-DOS only, heh) for quite a while, but I recently decided to
> > upgrade. And it didn't work, something was wrong (GPF whenever
>
> Why did you upgrade? I also like older versions for their smaller size.
Well, I had been using 2.03p2 (DJDEV203.ZIP), which is outdated, and
it makes it harder to compile some things (e.g. latest NASM). I think
I'll stick with GCC 3.44, though, because newer ones seem to use a lot
more memory (with -O2). Besides, some old code won't easily compile
with 4.x.
> > running, trying to compile latest NASM). I finally found out that it
> > was Binutils causing the problem (e.g. AS.EXE, which is kinda
> > important). It may be a UPX bug (at the very least, UPX 3.02 won't
> > unpack it!!), but I dunno. All I know is that /beta/BNU217B.ZIP
> > doesn't work in pure DOS or DOSBox (although QEMU/FreeDOS and things
> > like XP or Vista work fine): "invalid opcode" just for trying "as --
>
> Also works fine in Bochs CVS or Virtual PC 2004. Tried with MS-DOS 6.22
> HIMEM.SYS loaded and on clean boot.
Well, here's what pure MS-DOS 6.22 on real hardware says for me:
----------------------------------------------------------------------------------------------
[ MS-DOS ] Wed 03-12-2008>ver^memid^as --version
MS-DOS Version 6.22
[ MS-DOS ] Wed 03-12-2008>memid
PMODE VCPI 1.0 EMS 4.0 XMS 3.0
[ MS-DOS ] Wed 03-12-2008>as --version
Invalid Opcode at eip=7fcaa; flags=3206
eax=00000001 ebx=00001000 ecx=00000006 edx=00000006 esi=00123248
edi=00000001
ebp=00123288 esp=00123230 cs=a7 ds=af es=af fs=8f gs=0 ss=af
error=0006
[ MS-DOS ] Wed 03-12-2008>scrndump a:\b217beta.bug
----------------------------------------------------------------------------------------------
DOSBox 0.72 reports almost the same thing (except ecx=00000005 and
error=0002).
No clue why it would work under Windows and not real DOS. It *may* be
a genuine UPX bug (since 2.93-packed /current/ works but 3.01-packed /
beta/ doesn't), but I have no proof.
> > version" or "objdump --help". It was packed with UPX 3.01.
>
> I'm already using /beta/BNU217B.ZIP for some month on Windows 2000 and
> it always worked. Never tried in plain DOS, because I don't like to mess
> around with LFN.
You don't need LFN to use it. Just use a 16-bit unzipper (or "set
LFN=n" first). The only minor nit is that GCC344B.ZIP (from /beta/)
has LIB/GCC/DJGPP/3.44/limits.h which has this line:
#include "syslimits.h" // SFN expects "syslimit.h" so change
that
Otherwise, it works fine.
> > The workaround is to just use /current/BNU217B.ZIP instead (which
> > uses the 2.04 stub unlike /beta/MAK381B.ZIP or /beta/DIF287B.ZIP or /
> > beta/PAT259B.ZIP, strangely). It was packed with UPX 2.93. I also
> > recompiled Binutils myself (.EXEs only, see link below for download
> > info).
>
> Ah, thanks! :-) Can you reproduce the problem, when you pack your
> recompiled binaries with UPX 3.01?
I didn't try repacking until after I got it working. And then, in pure
DOS, using "--best" (with 3.02) seemed to not break anything (although
I didn't bother trying to unpack). (I actually didn't have enough
memory to pack CC1.EXE except with "-8".) It compiled TDEP and NASM
successfully, so that's good enough proof for me.
> > More detailed info can be found below:
>
> >http://sourceforge.net/tracker/index.php?func=detail&aid=1889631&grou...
BTW, not sure why Juan recompiled it himself when I already did it for
him. Oh well, to each his own. ;-)
- Raw text -