Recent changes to bugs

Problem with encoding of instructions

Anonymous — Tue, 08 Mar 2005 07:22:44 -0000

I'm not that good with x86 asm, but the following seens
to be a valid statement:

mov edx, dword ptr[esi - 4]

Using the intrinsics equivalent makes Softwire die a
horrible death by throwing INTERNAL_ERROR in
Synthesizer::encodeRegField (Synthesizer.cpp):

mov(edx, dword_ptr[esi - 4]);

Error with cygwin and gcc 3.4.1

Anonymous — Tue, 08 Mar 2005 07:19:24 -0000

On my system softwire crashed due to String.hpp:
#ifdef __GNUG__
inline int stricmp(const char *string1, const char
*string2)
{
return strcasecmp(string1, string2);
}
#endif

This will segfault on cygwin, I fixed using the following:

#ifdef __GNUG__
inline int stricmp(const char *string1, const char
*string2)
{
while(*string1 && *string2) {
if(tolower(*string1) != tolower(*string2))
return tolower(*string1) < tolower(*string2) ? -1 : 1;
++string1;
++string2;
}
return 0;
}
#endif

compilation error with gcc

Jüri Valdmann — Sun, 18 Apr 2004 08:08:54 -0000

with the latest CVS version of Softwire GCC 3.3.3 on linux says:
"c++ -fexceptions -fno-operator-names -g -c Test.cpp
Test.cpp:459: error: ISO C++ forbids declaration of `x' with no
type"

this can be fixed easily by changing "static x;" into "static int x;"

sfence() fails + crashes

Klaus Post — Sun, 07 Mar 2004 17:34:52 -0000

It seems like sfence() is crashing when used as intricsic.

Bug 1:
Somewhere in Encoding *Assembler::x86(..) sfence causes
an internal error. Probably in "encodeInstruction".

Bug 2:
The exception is caught by the try/catch, but "const
char *Parser::skipLine()" crashes, as "this" ("parser"
in HandleError) is not initialized.

Error in data after code from intrinsics

Anonymous — Wed, 14 Jan 2004 15:52:39 -0000

I have recently been having errors where I an compiling
a small script & using the intrinsics & I am placing
(labeled) static data in the memory area after the actual
function code.

In the generated code (in the echo file) the exact code
I am generating is reproduced correctly & all the labels
etc are correct.

However in the binary (compiled) version SoftWire has
(quite correctly) padded from my 'ret' instruction up to
the start of the nearest aligned boundary with 'nop's
(0x90).

The problem is that when it links the labels the first data
item points not to first label, but to the start of the
series of 'nop's (ie the first byte after the 'ret'); so that
the data when it is read is nonsense. All the subsequent
data items have the correct pointers, it is just the first
data item. The problem can be worked arround by
inserting an unlabeled dword ( ie CodeGenerator::dd(0) ).

I have been using version 4.20 with this error occuring
under MSVS.NET 2003.

nsb00@imperial.ac.uk

GCC (linux or mingw) makefiles missing in distribution

Krzysztof Foltman — Sat, 01 Mar 2003 09:51:02 -0000

Despite documentation, there are no Makefiles in
distribution

This is an example Makefile that successfully compiles
SoftWire in DLL form (as required by LGPL license) and
the example test proggy.

Small comment: the default .def file is autogenerated
(with all functions exported), but it's also possible
to cripple it a bit by hand, to remove references to
library functions etc.

============= cut ===================

SRC = Assembler.cpp \ Encoding.cpp \ Error.cpp \ Instruction.cpp \ InstructionSet.cpp \ Linker.cpp \ Loader.cpp \ Macro.cpp \ Operand.cpp \ Parser.cpp \ Scanner.cpp \ Synthesizer.cpp \ Token.cpp \ TokenList.cpp

OBJS = ${SRC:.cpp=.o}

CXXFLAGS = -fno-operator-names -O3
LIBS = stdc++

all: dll test

dll: softwire.dll

test: test.exe

test.exe: Test.o softwire.dll
gcc -L. -mconsole -o $@ Test.o -lsoftwire -lstdc++

softwire.dll: ${OBJS} softwire.def
dllwrap -o $@ ${LDFLAGS} ${OBJS} -lstdc++ --def
softwire.def --export-all-symbols --output-lib
libsoftwire.a

clean:
rm -f ${OBJS} Test.o

mrproper:
rm -f ${OBJS} Test.o test.exe softwire.dll

softwire.def: ${OBJS}
dllwrap -o $@ ${LDFLAGS} ${OBJS} -lstdc++ --output-def
softwire.def --export-all-symbols --output-lib
libsoftwire.a