I've tried using Boomerang on Mac OS X 10.4. Compilation went fine with gcc 4.0.1 (Apple's built shipped with OS X Developer Tools).
I'm running into the following errors :
1) Trying to run the testsuite :
-bash2.05b /src/src/boomerang $ make test
cd loader && make
make[1]: Nothing to be done for `all'.
cd loader && make test
cd .. ; loader/testLoader; cd -
.....Unable to open binary file: test/windows/calc.exe
unrecognised binary file format.
F...F
!!!FAILURES!!!
Test Results:
Run: 8 Failures: 2 Errors: 0
./bigtest
............................make: *** [test] Bus error
2) OK, bigtest is segfaulting. Let's see what's going wrong with gdb :
-bash2.05b /src/src/boomerang $ gdb bigtest
GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ....... done
(gdb) run
Starting program: /src/src/boomerang/bigtest
Reading symbols for shared libraries .+++ done
............................
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x001866a4 in Type::isPointerToAlpha (this=0x0) at type/type.cpp:1107
1107 return isPointer() && asPointer()->pointsToAlpha();
(gdb) bt
#0 0x001866a4 in Type::isPointerToAlpha (this=0x0) at type/type.cpp:1107
#1 0x000a2ae4 in Binary::simplifyConstraint (this=0x51062b0) at db/exp.cpp:3569
#2 0x000a29c8 in Binary::simplifyConstraint (this=0x51063a0) at db/exp.cpp:3561
#3 0x001ac9e4 in ExpTest::testSimpConstr (this=0xbfffe8c4) at db/ExpTest.cpp:779
#4 0x002d90cc in CppUnit::TestCaller<ExpTest>::runTest (this=0x5101c10) at /sw/include/cppunit/TestCaller.h:166
#5 0x04229fb0 in CppUnit::TestCaseMethodFunctor::operator() (this=0x0) at TestCase.cpp:32
#6 0x04209d68 in CppUnit::DefaultProtector::protect (this=0x51014e0, functor=@0x1c, context=@0xbfffe67c) at DefaultProtector.cpp:15
#7 0x0420f6b0 in CppUnit::ProtectorChain::protect (this=0x51014e0, functor=@0xbfffe6ec, context=@0xbfffe67c) at ProtectorChain.cpp:77
#8 0x04217944 in CppUnit::TestResult::protect (this=0xbfffe968, functor=@0xbfffe6ec, test=0x51062b0, shortDescription=@0x5106380) at TestResult.cpp:178
#9 0x04212108 in CppUnit::TestCase::run (this=0x5101c10, result=0xbfffe968) at TestCase.cpp:92
#10 0x04212c98 in CppUnit::TestComposite::doRunChildTests (this=0xbfffe8b0, controller=0xbfffe968) at TestComposite.cpp:64
#11 0x04212ad4 in CppUnit::TestComposite::run (this=0xbfffe8b0, result=0xbfffe968) at TestComposite.cpp:23
#12 0x00003dec in main (argc=1, argv=0xbfffeae0) at testAll.cpp:68
(gdb) quit
The program is running. Exit anyway? (y or n) y
3) Let's try using boomerang on a simple test case :
-bash2.05b /src/src/boomerang $ gdb boomerang
GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ...... done
Program received signal SIGABRT, Aborted.
0x9004802c in kill ()
So, my questions are :
- What version of boomerang can be considered as the latest and most stable one (and what tag should I pass to cvs in order to retrieve the source code for that version) ?
- Can someone point me to some test code that is working (or used to work) ?
Thanks in advance.
Aurelien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, Boomerang has probably never been tested on your test.o before. It would be much more useful to apply the functional tests, like this:
./functest.sh
This will run your copy of Boomerang against a set of about 70 small test cases, each of which is designed to test some aspect of decompilation. So for example if you can decompile hello but not twoproc, well it's something to do with parameters, since hello has no parameters but twoproc does. And so on.
With a .o file, you really need to specify entry points. Generally Boomerang in totally automatic mode tries to find main() (which it won't for a .o), and decompile it and all its children. Well, that won't work with a .o file.
You might thing that it's obvious that the user wants to decompile all the procs in the .o file, using the symbols to find the entry points. But usually you would be decompiling executables, which would have few if any symbols (main just might be one of the few). Support for .o files is not great at this stage; the emphasis is on executables.
So please try the functional test suite; note that not all tests pass at present (even a few of the ones that it looks as though should pass). However, on a non-Windows host, I would expect everything up to but not including nestedswitch to work, with one exception: pentium minmax3 (which has a comment to that effect).
If those work OK, then we can be satisfied that this is not a Mac OS/X issue. Similarly, if tests before nestedswitch fail, we can start narrowing down the problem(s).
- Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How do you compile boomerang under osX. I've got a 10.4.8/intel build, and ./configure says
checking cppunit/TestSuite.h usability... no
checking cppunit/TestSuite.h presence... no
checking for cppunit/TestSuite.h... no
checking for include/cppunit/TestSuite.h... no
checking for cppunit/TestSuite.h... :
configure:
configure: Header directories for cppunit not found; needed only for unit testing.
configure:
checking for _ZN7CppUnit8TestCase3runEv in -lcppunit... no
checking for lib/libcppunit.a... no
checking for libcppunit.a... :
configure:
configure: cppunit (C++ Unit Testing) library not found; needed only for testing
configure:
then make says :
cd loader && make
g++ -g -O2 -Wall -o ../lib/libBinaryFile.dylib -dynamic -dylib BinaryFile.o SymTab.o
/usr/bin/ld: Undefined symbols:
_main
collect2: ld returned 1 exit status
make[1]: *** [../lib/libBinaryFile.dylib] Error 1
make: *** [loaders] Error 2
I can't compile...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
cppunit is unused at present ("needed only for unit testing")
It seems to have something to do with the creation of the dynamic library. I really have no idea how this is supposed to work on OSX, but I found the following in loader/Makefile.in
ifeq ($(HOST_OSX), yes)
ifeq ($HOST_OSX_10_2), yes)
SHARED=-dynamiclib # Note: doesn't seem to work at present; fiddle manually
else
SHARED=-dynamic -dylib
endif
#-flat_namespace
DLLEXT=.dylib
RUNPATH=
else # Non-OS X
SHARED=-shared
endif
Try adding an entry for HOST_OSX_10_4 (it probably needs -dynamiclib) and run ./config.status to regenerate the Makefiles.
Good luck, and if you get it to work, could you please post the solution?
- Gerard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had to make three changes to get it to build correctly on OS X 10.4:
1. in loader/Makefile, change it to always use -dynamiclib, not just on 10.2. I have the feeling this hasn't been updated since 10.3 came out, and that should really mean >=10.2, and if anyone out there is still using 10.1... too bad.
2. There was a line in the toplevel Makefile that caused it to erroneously pass -R"lib" on the command line -- remove that.
3. Back in loader/Makefile, change all references from ../lib/whatever to just whatever -- otherwise, you end up with libraries with installnames of "../lib/libwhatever" -- this will compile fine, but choke when you try to run boomerang. If anyone wants me to elaborate / clean up this point, I can try.
Ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I've tried using Boomerang on Mac OS X 10.4. Compilation went fine with gcc 4.0.1 (Apple's built shipped with OS X Developer Tools).
I'm running into the following errors :
1) Trying to run the testsuite :
-bash2.05b /src/src/boomerang $ make test
cd loader && make
make[1]: Nothing to be done for `all'.
cd loader && make test
cd .. ; loader/testLoader; cd -
.....Unable to open binary file: test/windows/calc.exe
unrecognised binary file format.
F...F
!!!FAILURES!!!
Test Results:
Run: 8 Failures: 2 Errors: 0
1) test: LoaderTest (F) line: 206 LoaderTest.cpp
assertion failed
- Expression: pBF != NULL
2) test: LoaderTest (F) line: 602 LoaderTest.cpp
assertion failed
- Expression: dlHandle
./bigtest
............................make: *** [test] Bus error
2) OK, bigtest is segfaulting. Let's see what's going wrong with gdb :
-bash2.05b /src/src/boomerang $ gdb bigtest
GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ....... done
(gdb) run
Starting program: /src/src/boomerang/bigtest
Reading symbols for shared libraries .+++ done
............................
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x001866a4 in Type::isPointerToAlpha (this=0x0) at type/type.cpp:1107
1107 return isPointer() && asPointer()->pointsToAlpha();
(gdb) bt
#0 0x001866a4 in Type::isPointerToAlpha (this=0x0) at type/type.cpp:1107
#1 0x000a2ae4 in Binary::simplifyConstraint (this=0x51062b0) at db/exp.cpp:3569
#2 0x000a29c8 in Binary::simplifyConstraint (this=0x51063a0) at db/exp.cpp:3561
#3 0x001ac9e4 in ExpTest::testSimpConstr (this=0xbfffe8c4) at db/ExpTest.cpp:779
#4 0x002d90cc in CppUnit::TestCaller<ExpTest>::runTest (this=0x5101c10) at /sw/include/cppunit/TestCaller.h:166
#5 0x04229fb0 in CppUnit::TestCaseMethodFunctor::operator() (this=0x0) at TestCase.cpp:32
#6 0x04209d68 in CppUnit::DefaultProtector::protect (this=0x51014e0, functor=@0x1c, context=@0xbfffe67c) at DefaultProtector.cpp:15
#7 0x0420f6b0 in CppUnit::ProtectorChain::protect (this=0x51014e0, functor=@0xbfffe6ec, context=@0xbfffe67c) at ProtectorChain.cpp:77
#8 0x04217944 in CppUnit::TestResult::protect (this=0xbfffe968, functor=@0xbfffe6ec, test=0x51062b0, shortDescription=@0x5106380) at TestResult.cpp:178
#9 0x04212108 in CppUnit::TestCase::run (this=0x5101c10, result=0xbfffe968) at TestCase.cpp:92
#10 0x04212c98 in CppUnit::TestComposite::doRunChildTests (this=0xbfffe8b0, controller=0xbfffe968) at TestComposite.cpp:64
#11 0x04212ad4 in CppUnit::TestComposite::run (this=0xbfffe8b0, result=0xbfffe968) at TestComposite.cpp:23
#12 0x00003dec in main (argc=1, argv=0xbfffeae0) at testAll.cpp:68
(gdb) quit
The program is running. Exit anyway? (y or n) y
3) Let's try using boomerang on a simple test case :
-bash2.05b /src/src/boomerang $ ./boomerang /tmp/test.o
Boomerang alpha 0.3.1 09/Sep/2006
loading...
Segmentation fault
4) Segfault again. What's happening in gdb ?
-bash2.05b /src/src/boomerang $ gdb boomerang
GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ...... done
(gdb) run /tmp/test.o
Starting program: /src/src/boomerang/boomerang /tmp/test.o
Reading symbols for shared libraries .++ done
Boomerang alpha 0.3.1 09/Sep/2006
loading...
Reading symbols for shared libraries . done
decoding entry point...
decoding anything undecoded...
finishing decode...
found 0 procs
decompiling...
db/prog.cpp:1272: failed assertion `m_procs.size()'
Program received signal SIGABRT, Aborted.
0x9004802c in kill ()
So, my questions are :
- What version of boomerang can be considered as the latest and most stable one (and what tag should I pass to cvs in order to retrieve the source code for that version) ?
- Can someone point me to some test code that is working (or used to work) ?
Thanks in advance.
Aurelien
> I've tried using Boomerang on Mac OS X 10.4.
Good on you. There have been issues.
> Compilation went fine with gcc 4.0.1 (Apple's built shipped with OS X Developer Tools).
> I'm running into the following errors :
> 1) Trying to run the testsuite :
> -bash2.05b /src/src/boomerang $ make test
> ...
> !!!FAILURES!!!
Ah, this is the unit testing. This is now deprecated. It would be nice to get it working again, but we don't have the manpower.
For now, please ignore the unit tests.
> 3) Let's try using boomerang on a simple test case :
> -bash2.05b /src/src/boomerang $ ./boomerang /tmp/test.o
> Boomerang alpha 0.3.1 09/Sep/2006
This is a recent version. Good.
> loading...
> Segmentation fault
Well, Boomerang has probably never been tested on your test.o before. It would be much more useful to apply the functional tests, like this:
./functest.sh
This will run your copy of Boomerang against a set of about 70 small test cases, each of which is designed to test some aspect of decompilation. So for example if you can decompile hello but not twoproc, well it's something to do with parameters, since hello has no parameters but twoproc does. And so on.
> ... found 0 procs
> decompiling...
> db/prog.cpp:1272: failed assertion
`m_procs.size()'
With a .o file, you really need to specify entry points. Generally Boomerang in totally automatic mode tries to find main() (which it won't for a .o), and decompile it and all its children. Well, that won't work with a .o file.
You might thing that it's obvious that the user wants to decompile all the procs in the .o file, using the symbols to find the entry points. But usually you would be decompiling executables, which would have few if any symbols (main just might be one of the few). Support for .o files is not great at this stage; the emphasis is on executables.
So please try the functional test suite; note that not all tests pass at present (even a few of the ones that it looks as though should pass). However, on a non-Windows host, I would expect everything up to but not including nestedswitch to work, with one exception: pentium minmax3 (which has a comment to that effect).
If those work OK, then we can be satisfied that this is not a Mac OS/X issue. Similarly, if tests before nestedswitch fail, we can start narrowing down the problem(s).
- Mike
How do you compile boomerang under osX. I've got a 10.4.8/intel build, and ./configure says
checking cppunit/TestSuite.h usability... no
checking cppunit/TestSuite.h presence... no
checking for cppunit/TestSuite.h... no
checking for include/cppunit/TestSuite.h... no
checking for cppunit/TestSuite.h... :
configure:
configure: Header directories for cppunit not found; needed only for unit testing.
configure:
checking for _ZN7CppUnit8TestCase3runEv in -lcppunit... no
checking for lib/libcppunit.a... no
checking for libcppunit.a... :
configure:
configure: cppunit (C++ Unit Testing) library not found; needed only for testing
configure:
then make says :
cd loader && make
g++ -g -O2 -Wall -o ../lib/libBinaryFile.dylib -dynamic -dylib BinaryFile.o SymTab.o
/usr/bin/ld: Undefined symbols:
_main
collect2: ld returned 1 exit status
make[1]: *** [../lib/libBinaryFile.dylib] Error 1
make: *** [loaders] Error 2
I can't compile...
cppunit is unused at present ("needed only for unit testing")
It seems to have something to do with the creation of the dynamic library. I really have no idea how this is supposed to work on OSX, but I found the following in loader/Makefile.in
ifeq ($(HOST_OSX), yes)
ifeq ($HOST_OSX_10_2), yes)
SHARED=-dynamiclib # Note: doesn't seem to work at present; fiddle manually
else
SHARED=-dynamic -dylib
endif
#-flat_namespace
DLLEXT=.dylib
RUNPATH=
else # Non-OS X
SHARED=-shared
endif
Try adding an entry for HOST_OSX_10_4 (it probably needs -dynamiclib) and run ./config.status to regenerate the Makefiles.
Good luck, and if you get it to work, could you please post the solution?
- Gerard
I had to make three changes to get it to build correctly on OS X 10.4:
1. in loader/Makefile, change it to always use -dynamiclib, not just on 10.2. I have the feeling this hasn't been updated since 10.3 came out, and that should really mean >=10.2, and if anyone out there is still using 10.1... too bad.
2. There was a line in the toplevel Makefile that caused it to erroneously pass -R"lib" on the command line -- remove that.
3. Back in loader/Makefile, change all references from ../lib/whatever to just whatever -- otherwise, you end up with libraries with installnames of "../lib/libwhatever" -- this will compile fine, but choke when you try to run boomerang. If anyone wants me to elaborate / clean up this point, I can try.
Ben