/beta/bnu217b.zip won't work in pure DOS (UPX bug??)
Rugxulo
It's been seven months since I reported /beta/BNU217B.ZIP was too
big because it still had debug info and hadn't been stripped. And I've
been using the latest Binutils 2.17 on both XP and Vista with no
apparent problems. However, after Gordon (I think) updated the
package, he also UPX'd the binaries.
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
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 --
version" or "objdump --help". It was packed with UPX 3.01.
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).
More detailed info can be found below:
http://sourceforge.net/tracker/index.php?func=detail&aid=1889631&group_id=2331&atid=102331
Robert Riebisch
> 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.
> 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.
> 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.
> 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?
> More detailed info can be found below:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1889631&group_id=2331&atid=102331
You found my bug report. :-)
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
Juan Manuel Guerrero
> Hey,
> It's been seven months since I reported /beta/BNU217B.ZIP was too
> big because it still had debug info and hadn't been stripped. And I've
> been using the latest Binutils 2.17 on both XP and Vista with no
> apparent problems. However, after Gordon (I think) updated the
> package, he also UPX'd the binaries.
I have uploaded a new release of /beta/BNU217B.ZIP some months ago.
I have manually strped the binaries contained in the original
zip file and compressed them with UPX. Later a discussion started
about the usfullness of UPX and I have stopped the compress binaries
but I have not changed this package again.
I will recompile the sources from scratch with stock djdev204 and
replace the existing beta package.
Regards,
Juan M. Guerrero
Rugxulo
On Mar 28, 3:44 am, Robert Riebisch <Robert.Riebi...@arcor.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. ;-)
Robert Riebisch
> 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.
That's why I have a multi-version GCC on Windows 2000. ;-) Yes, I killed
Ubuntu.
> [ MS-DOS ] Wed 03-12-2008>memid
> PMODE VCPI 1.0 EMS 4.0 XMS 3.0
Did you try a clean boot?
> [ 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
Does UPX use SSE? *g*
http://www.delorie.com/djgpp/bugs/show.cgi?000372
Rugxulo
On Mar 28, 3:42 pm, Robert Riebisch <Robert.Riebi...@arcor.de> wrote:
> Rugxulo wrote:
> > 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.
>
> That's why I have a multi-version GCC on Windows 2000. ;-) Yes, I killed
> Ubuntu.
What for? I thought you liked it, and it worked well? What went wrong?
> > [ MS-DOS ] Wed 03-12-2008>memid
> > PMODE VCPI 1.0 EMS 4.0 XMS 3.0
>
> Did you try a clean boot?
Yes. No difference.
> > [ 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
>
> Does UPX use SSE? *g*http://www.delorie.com/djgpp/bugs/show.cgi?000372
I don't think so, but that would explain why it works in QEMU/Win32
(which supports SSE) and not DOSBox (486DX only). AFAICT, the only way
for GCC to use SSE is either through -msse, -mfpmath=sse, or maybe?
with -march=native. I can't test right now, but HDPMI32 automatically
turns on SSE support if available, so you could try running that first
then "as.exe --version" on your Pentium M, and see what happens. ;-)
LZMA has been supported in UPX since 2.90 (according to their NEWS
file). And yet /current/ was packed with 2.93 "unstable" and works
yet /beta/ with 3.01 "stable" doesn't. Odd. I have no idea.
Robert Riebisch
> > That's why I have a multi-version GCC on Windows 2000. ;-) Yes, I killed
> > Ubuntu.
>
> What for? I thought you liked it, and it worked well? What went wrong?
It hung after resume. Yes, it worked well, but Windows 2000 works better
(for me).
> > Does UPX use SSE? *g*http://www.delorie.com/djgpp/bugs/show.cgi?000372
>
> I don't think so, but that would explain why it works in QEMU/Win32
> (which supports SSE) and not DOSBox (486DX only). AFAICT, the only way
> for GCC to use SSE is either through -msse, -mfpmath=sse, or maybe?
No idea.
> with -march=native. I can't test right now, but HDPMI32 automatically
> turns on SSE support if available, so you could try running that first
> then "as.exe --version" on your Pentium M, and see what happens. ;-)
I don't have a working real DOS here currently.
> LZMA has been supported in UPX since 2.90 (according to their NEWS
> file). And yet /current/ was packed with 2.93 "unstable" and works
> yet /beta/ with 3.01 "stable" doesn't. Odd. I have no idea.
Just verified: Both files show method 14 ("LZMA") in their UPX header.
Rugxulo
On Mar 28, 3:44 am, Robert Riebisch <Robert.Riebi...@arcor.de> wrote:
>
> Ah, thanks! :-) Can you reproduce the problem, when you pack your
> recompiled binaries with UPX 3.01?
If I try running the broken binary under DOSBox with latest HDPMI32,
it gives me the following:
[EIP]=0F 45 C1 66 A3 18 32 0A 00 0F B6 5D
... which, run through HIEW, says this:
00000000: 0F45C1 cmovne
ax,cx
And that is clearly not supported on my 486, P166 (no MMX), nor in
DOSBox (486DX). Maybe Gordon (who did the /beta/ port, right?) has a
P2 and wanted the extra runtime speed from "-march" optimizations?? I
dunno, only guessing.
For the AS-NEW.EXE that I rebuilt yesterday, I tried a lot of
compression options for both UPX 3.01 and 3.02 (DOS version), and no
problems running under DOSBox 0.72. (No compression differences b/w
UPX 3.01 for DJGPP stuff and 3.02, only an internal version variable
difference:
[ WinXP ] Fri 03/28/2008>fc ultbrute.ex ultbrute.exe /b | more
Comparing files ultbrute.ex and ULTBRUTE.EXE
00000905: 31 32
I also did a quick grep in UPX 3.01's sources and found no mentions of
CMOV, so it must be a DJGPP port issue (although UPX was strangely
able to unpack all of these 2.04 .EXEs, so who knows). So, this issue
is probably not a direct UPX bug, AFAICT.
Rugxulo
On Mar 28, 5:19 pm, Robert Riebisch <Robert.Riebi...@arcor.de> wrote:
> Rugxulo wrote:
> > > That's why I have a multi-version GCC on Windows 2000. ;-) Yes, I killed
> > > Ubuntu.
>
> > What for? I thought you liked it, and it worked well? What went wrong?
>
> It hung after resume. Yes, it worked well, but Windows 2000 works better
> (for me).
Resume from hibernation or sleep? Yes, I think that's a known issue,
limited (or flaky) ACPI support in Linux (or at least Ubuntu). Gotta
love all these newer hardware standards that nobody supports. And
after we finally got up-to-date on all the old stuff. :-( I
still say you should consider playing with PC BSD (or a liveCD variant
or whatever), but that's coming from a *nix-phobe who's never tried
it. ;-)
> > > Does UPX use SSE? *g*http://www.delorie.com/djgpp/bugs/show.cgi?000372
>
> > I don't think so, but that would explain why it works in QEMU/Win32
> > (which supports SSE) and not DOSBox (486DX only). AFAICT, the only way
> > for GCC to use SSE is either through -msse, -mfpmath=sse, or maybe?
>
> No idea.
Actually, it looks like it's an offending "CMOV" instruction instead.
> > with -march=native. I can't test right now, but HDPMI32 automatically
> > turns on SSE support if available, so you could try running that first
> > then "as.exe --version" on your Pentium M, and see what happens. ;-)
>
> I don't have a working real DOS here currently.
Try a liveCD of FreeDOS. :-) (BTW, you don't need to test now
anyways.)
> > LZMA has been supported in UPX since 2.90 (according to their NEWS
> > file). And yet /current/ was packed with 2.93 "unstable" and works
> > yet /beta/ with 3.01 "stable" doesn't. Odd. I have no idea.
>
> Just verified: Both files show method 14 ("LZMA") in their UPX header.
You know UPX is compiled with NRV, right? So, unless there's some
weird bug in that (since all we have is the FOSS replacement UCL),
it's probably just a mistake when ported to DJGPP (e.g. using "-
march=pentium2").
Cesar Rabak
> Hi,
[snipped]
> 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).
Just to grasp completely your report is the "almost the same thing" in
_the same phisical machine_?
Rugxulo
On Mar 28, 6:28 pm, Cesar Rabak <csra...@yahoo.com.br> wrote:
> Rugxulo escreveu:> Hi,
>
> [snipped]
>
> > Well, here's what pure MS-DOS 6.22 on real hardware says for me:
>
> > DOSBox 0.72 reports almost the same thing (except ecx=00000005 and
> > error=0002).
>
> Just to grasp completely your report is the "almost the same thing" in
> _the same phisical machine_?
No. The MS-DOS 6.22 computer is a 486 Sx/25 with 8 MB of RAM (heh), so
it's real hardware. I ran DOSBox 0.72 (emulation) on this cpu right
here, Pentium 4 "Northwood" 2.52 Ghz w/ 512 MB RAM (Win XP Home SP2).
But DOSBox emulates a 486DX2, so the instructions supported are
similar.
As mentioned in the other posts, it appears to be an errant CMOVNE
(PPro/P2) instruction, which is not supported on 486s or original
Pentiums.
Cesar Rabak
> Hi,
>
> On Mar 28, 6:28 pm, Cesar Rabak <csra...@yahoo.com.br> wrote:
>> Rugxulo escreveu:> Hi,
>>
>> [snipped]
>>
>>> Well, here's what pure MS-DOS 6.22 on real hardware says for me:
>>> DOSBox 0.72 reports almost the same thing (except ecx=00000005 and
>>> error=0002).
>> Just to grasp completely your report is the "almost the same thing" in
>> _the same phisical machine_?
>
> No. The MS-DOS 6.22 computer is a 486 Sx/25 with 8 MB of RAM (heh), so
> it's real hardware. I ran DOSBox 0.72 (emulation) on this cpu right
> here, Pentium 4 "Northwood" 2.52 Ghz w/ 512 MB RAM (Win XP Home SP2).
> But DOSBox emulates a 486DX2, so the instructions supported are
> similar.
OK, due above my reasoning is moot by now, but I asked to see if it
could be explained by malfunctioning memory modules (have been bitten by
this, specially in older HW where sometimes people had more than 2MB of
memory but used strictly DOS apps and never 'knew' higher memory to be
marginally operational).
>
> As mentioned in the other posts, it appears to be an errant CMOVNE
> (PPro/P2) instruction, which is not supported on 486s or original
> Pentiums.
Yes. I only saw the other post _after_ I've already posted my question.
regards.
Rugxulo
(e.g. "cmovne ax,cx"):
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gdb64b.zip
The GDB.EXE is also the same one they are shipping with FreeBASIC
(even latest 0.18.4b)! So now I have to go inform them as well! :-P
P.S. Juan, I don't know if that affects the gdb64a.zip package since I
have no easy way to test (and the filedate is different, not from the
same time period), so caveat emptor there.
Rugxulo
On Mar 30, 5:16 pm, Rugxulo <rugx...@gmail.com> wrote:
> I found at least one other package that uses such PPro instructions
> (e.g. "cmovne ax,cx"):
>
> ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gdb64b.zip
>
> The GDB.EXE is also the same one they are shipping with FreeBASIC
> (even latest 0.18.4b)! So now I have to go inform them as well! :-P
coderJeff (from FreeBASIC) still has his local DOS build of GDB 6.4
for 386 from a year ago, and I successfully tested it on 486, 586, and
DOSBox:
http://rugxulo.googlepages.com/gdb-64b.7z (.EXE only, 1388k)