W Wrapl, The Programming Language

The Udis86 Disassembler

The Udis86 Disassemblerby FatherBrain on Thu Dec 04, 2008 8:08 pm

Hi Folks,

I have taken up the challenge to build WRAPL under Cygwin. It took me a while to get all the required packages listed on the download page. Once I started to build, I stumbled upon one more requirement: for some Intel *86 platforms, the Udis86 Disassembler library must be installed: see http://sourceforge.net/projects/udis86. You may wish to update the on-line documentation to mention this requirement.

Also, it appears that the build procedure requires Yasm, even if Nasm is present. Is Yasm really required? If so, the documentation should not read "Nasm or Yasm". And if Nasm can safely used in place of Yasm, the build procedure should build when either assembler is available.

Wish me luck with the rest of the build.

Sincerely,
Frank



Re: The Udis86 Disassemblerby rajamukherji on Sun Dec 07, 2008 9:58 pm

FatherBrain wrote:Hi Folks,

I have taken up the challenge to build WRAPL under Cygwin. It took me a while to get all the required packages listed on the download page. Once I started to build, I stumbled upon one more requirement: for some Intel *86 platforms, the Udis86 Disassembler library must be installed: see http://sourceforge.net/projects/udis86. You may wish to update the on-line documentation to mention this requirement.


Thanks for pointing that out. Originally Udis86 was only used optionally in the Wrapl compiler for debugging the generated machine code if certain macros were defined. Since I've never released a version with the macros defined, I didn't list Udis86 as a requirement. However, at some stage I changed the linker rlink to generate a disassembly of the linked code so I could debug modules written in C/assembly and I forgot to update the build requirements. I might make this disassembly optional so that udis86 would not be a requirement at all, since I don't think that the disassembly is that useful unless you are building your own C/assembly modules.

Also, it appears that the build procedure requires Yasm, even if Nasm is present. Is Yasm really required? If so, the documentation should not read "Nasm or Yasm". And if Nasm can safely used in place of Yasm, the build procedure should build when either assembler is available.


It really should build with either Yasm or Nasm, at least on Linux it seems to detect correctly which is present. However, I do recommend Yasm for building, some versions of Nasm seem to crash because of the large number of sections in the source code but recent versions should work.

Wish me luck with the rest of the build.

Sincerely,
Frank


Good luck with the build!


P.S. The source code on the download page is slightly updated from that of the last Cygwin build but as far as I can remember I didn't change anything affecting the Windows code.



Re: The Udis86 Disassemblerby FatherBrain on Mon Dec 08, 2008 1:21 pm

After installing Yasm and Udis86, I hit one more snag building under Cygwin: the building of lib/Gmp.riva requires the file cygwin1.rlib. What is the best way to obtain the cygwin1.rlib file? Is there a tool for generating this file?



Re: The Udis86 Disassemblerby rajamukherji on Mon Dec 08, 2008 2:19 pm

FatherBrain wrote:After installing Yasm and Udis86, I hit one more snag building under Cygwin: the building of lib/Gmp.riva requires the file cygwin1.rlib. What is the best way to obtain the cygwin1.rlib file? Is there a tool for generating this file?



The cygwin1.rlib file should be the /dev/lib/ folder and contain
Code: Select all
module("cygwin1")
export("???")
...


where each export from the cygwin1.dll file gets a export separate line. On Linux, the script /dev/bin/rimplib generates the .rlib files from .so files but on Windows I use something like http://www.dependencywalker.com/, copy the list of exported functions and use a decent editor to generate the .rlib file manually.

I'll attach the most recent version I made but since I haven't used Cygwin in a while, I'm not sure if it's still accurate.

Attachments
cygwin1.rlib.gz
(5.63 KiB) Downloaded 268 times


Re: The Udis86 Disassemblerby FatherBrain on Mon Dec 08, 2008 9:33 pm

OK, now that I have cygwin1.rlib, my build hit another snag. The file /lib/IO/Terminal.riva could not be built because the linker could not resolve the symbol Std$Type$New.invoke. Looking for where this symbol might come from, I found the following declaration in the file dev/inc/gcc/Std/Type.h:
Code: Select all
extern void *Std$Type$default_invoke(void) asm("Std$Type$New.invoke");
Is this a call to an assembly routine defined somewhere else? How does one define Std$Type$default_invoke for the Cygwin environment?



Re: The Udis86 Disassemblerby rajamukherji on Tue Dec 09, 2008 2:35 am

FatherBrain wrote:OK, now that I have cygwin1.rlib, my build hit another snag. The file /lib/IO/Terminal.riva could not be built because the linker could not resolve the symbol Std$Type$New.invoke. Looking for where this symbol might come from, I found the following declaration in the file dev/inc/gcc/Std/Type.h:
Code: Select all
extern void *Std$Type$default_invoke(void) asm("Std$Type$New.invoke");
Is this a call to an assembly routine defined somewhere else? How does one define Std$Type$default_invoke for the Cygwin environment?


The line
Code: Select all
extern void *Std$Type$default_invoke(void) asm("Std$Type$New.invoke");

should probably be replaced with
Code: Select all
extern void *Std$Type$default_invoke(void) asm("_Std$Type$New.invoke");

when building on Cygwin.
If this works, I'll replace it with a #ifdef.

P.S. Std$Type$New.invoke is defined in /dev/src/Lib/Std/Type.asm. In general Dir$Module$Id is defined in /dev/src/Lib/Dir/Module.(c/asm).



Re: The Udis86 Disassemblerby FatherBrain on Mon Dec 15, 2008 1:45 pm

I hit another snag with making a Cygwin build, using the compiler gcc version 3.4.4. The source file /dev/src/Lib/DB/Sqlite3.c includes <sys/cygwin.h>, which in turn includes <sys/resource.h>. The <sys/resource.h> header has a declaration that depends on the struct timeval. The header /usr/include/sys/time.h declares struct timeval, so <sys/resource.h> includes <sys/time.h>.

When Sqlite3.c is preprocessed with the build procedure include paths, however, the <sys/time.h> include directive actually includes the file /dev/inc/gcc/Sys/Time.h. This file does not declare struct timeval, causing the compilation of Sqlite3.c to fail!

Are there any recommendations as to how to fix this?



Re: The Udis86 Disassemblerby rajamukherji on Mon Dec 15, 2008 2:03 pm

FatherBrain wrote:I hit another snag with making a Cygwin build, using the compiler gcc version 3.4.4. The source file /dev/src/Lib/DB/Sqlite3.c includes <sys/cygwin.h>, which in turn includes <sys/resource.h>. The <sys/resource.h> header has a declaration that depends on the struct timeval. The header /usr/include/sys/time.h declares struct timeval, so <sys/resource.h> includes <sys/time.h>.

When Sqlite3.c is preprocessed with the build procedure include paths, however, the <sys/time.h> include directive actually includes the file /dev/inc/gcc/Sys/Time.h. This file does not declare struct timeval, causing the compilation of Sqlite3.c to fail!

Are there any recommendations as to how to fix this?


Hmmmm, this is a strange problem indeed. I guess it is due to the lack of case sensitivity on Windows. I suppose the easiest thing to do for now is renaming Sys/Time.h and replacing the few references to it in any other source files. I think Sys/Time.c and Sys/FileSys.c are the only files that reference it.

I'll probably move all the include files into a separate folder to prevent any other problems, something like Riva/Sys/Time.h for example.



Who is online

Users browsing this forum: No registered users and 1 guest

cron