New Debugger branch - Functional

[Richard42]

I also figured out what's up with the "random" jumping around in the disassembler. It doesn't handle branches properly. If you step over a branch it steps to the second instruction after that and then branches, and if you step over a JAL, it doesn't follow it. Similarly if you put a breakpoint on an instruction two after a branch, the breakpoint hits when the branch is executed, even if it would have skipped the actual instruction the breakpoint is on.

I filed an issue report in the google issue tracker about some debugger improvements. One of the improvements that I listed is fixing the strange stepping behavior around branches.

I added a logging function to glN64, but how would I go about communicating with the plugin from the GUI code to tell it when to start and stop logging?

You have to go through the DLL interface to communicate between the core and the plugins. This would mean extending the video plugin API.

 

[HyperHacker]

DLL interface? Does that apply to Linux too? I wonder if the plugin can't simply catch key press events for its output window.

 

[Richard42]

DLL interface? Does that apply to Linux too? I wonder if the plugin can't simply catch key press events for its output window.

Yes, that does apply to linux. The video plugin is a shared library, so the communication has to go through that shared library API. The SDL events (keypresses, joystick movements, etc) are caught in the core and are passed to the input plugin, but not the video plugin. The video plugin only uses the OpenGL window.

 

[HyperHacker]

So after reinstalling Xubuntu on a new hard drive, I had to symlink /usr/lib/libopcodes-[bunch of numbers].so as /usr/lib/libopcodes.so, and the same for libbfd.so, to be able to compile the emulator. Seems like a makefile problem?

 

[Richard42]

So after reinstalling Xubuntu on a new hard drive, I had to symlink /usr/lib/libopcodes-[bunch of numbers].so as /usr/lib/libopcodes.so, and the same for libbfd.so, to be able to compile the emulator. Seems like a makefile problem?

I think that's a system problem. The makefile just tells the linker that it wants a certain library with a flag "-lopcodes -lbfd", and if the linker can't find the library then it's not installed or the system isn't configured properly.

 

[HyperHacker]

Odd, they are installed, and it's happened on fresh installs on two different machines. Maybe there's a problem with these libraries?

 

[Richard42]

Odd, they are installed, and it's happened on fresh installs on two different machines. Maybe there's a problem with these libraries?

I just tried it on a couple of my machines. The first one is my main desktop, a gentoo box. It compiles and runs fine there, and as you can see the .so files are there. The second is Fedora 8, my HTPC box. I don't think I've tried to compile the debugger there. Interestingly enough, it does not have the base .so files. I wonder if it's some kind of packaging issue.

21:59:01  ~ > locate libopcodes
/usr/i686-pc-linux-gnu/lib/libopcodes.so
/usr/i686-pc-linux-gnu/lib/libopcodes-2.18.so
/usr/x86_64-pc-linux-gnu/lib/libopcodes.la
/usr/x86_64-pc-linux-gnu/lib/libopcodes.so
/usr/x86_64-pc-linux-gnu/lib/libopcodes-2.18.so
/usr/x86_64-pc-linux-gnu/lib/libopcodes.a
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libopcodes.la
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libopcodes.so
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libopcodes-2.18.so
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libopcodes.a
21:59:06  ~ > locate libbfd
/usr/i686-pc-linux-gnu/lib/libbfd-2.18.so
/usr/i686-pc-linux-gnu/lib/libbfd.so
/usr/x86_64-pc-linux-gnu/lib/libbfd.a
/usr/x86_64-pc-linux-gnu/lib/libbfd-2.18.so
/usr/x86_64-pc-linux-gnu/lib/libbfd.la
/usr/x86_64-pc-linux-gnu/lib/libbfd.so
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libbfd.a
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libbfd-2.18.so
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libbfd.la
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.18/libbfd.so
21:59:22  ~ > 
22:11:46  ~ > 
22:11:46  ~ > 
22:11:51  ~ > ssh vgmuseum@arcadia 
vgmuseum@arcadia's password: 
Last login: Sat Aug 23 00:06:26 2008 from dualcore64
[vgmuseum@Arcadia ~]$ locate libopcodes
/usr/lib/libopcodes.a
/usr/lib64/libopcodes-2.17.50.0.18-1.so
/usr/lib64/libopcodes.a
[vgmuseum@Arcadia ~]$ locate libbfd
/usr/lib/libbfd.a
/usr/lib64/libbfd-2.17.50.0.18-1.so
/usr/lib64/libbfd.a
[vgmuseum@Arcadia ~]$

 

[HyperHacker]

That's about the same as what I get:

hyperhacker@mercury:~$ locate libopcodes
/home/hyperhacker/dev/mingw/lib/libopcodes.a
/home/hyperhacker/dev/mingw/lib/libopcodes.la
/usr/lib/libopcodes-2.18.0.20080103.so
/usr/lib/libopcodes.so
hyperhacker@mercury:~$ locate libbfd
/home/hyperhacker/dev/mingw/lib/libbfd.a
/home/hyperhacker/dev/mingw/lib/libbfd.la
/usr/lib/libbfd-2.18.0.20080103.so
/usr/lib/libbfd.so
hyperhacker@mercury:~$

I created the libopcodes.so and libfd.so links manually.

 

[Slougi]

For the record, on arch linux:

[slougi@gondolin ~]$ ls -l /usr/lib/libbfd*
-rwxr-xr-x 1 root root 703251 2008-06-12 17:01 /usr/lib/libbfd-2.18.0.20080610.so
-rw-r--r-- 1 root root 714524 2008-06-12 17:01 /usr/lib/libbfd.a
[slougi@gondolin ~]$ ls -l /usr/lib/libopcodes*
-rwxr-xr-x 1 root root 200574 2008-06-12 17:01 /usr/lib/libopcodes-2.18.0.20080610.so
-rw-r--r-- 1 root root 210396 2008-06-12 17:01 /usr/lib/libopcodes.a
[slougi@gondolin ~]$

 

[Günther1]

So after reinstalling Xubuntu on a new hard drive, I had to symlink /usr/lib/libopcodes-[bunch of numbers].so as /usr/lib/libopcodes.so, and the same for libbfd.so, to be able to compile the emulator. Seems like a makefile problem?

Try installing binutils-dev. Usually, those symlinks are separately packaged together with headers etc. because they are only needed to build applications, not to run them.

 

[HyperHacker]

I just built the SVN version (after many failed attempts to check it out, "connection reset by peer") and the debugger is broken. Whenever you pause (using the >\|| button, breakpoints, etc) it automatically steps through the code as if you were continuously clicking Next. (It does look neat though. Maybe adding a way to step through a specified number of instructions or step to the next breakpoint like this would be useful.)

The problem seems to be that this (debugger/debugger.c:91) isn't doing anything:

// Emulation thread is blocked until a button is clicked.
    SDL_CondWait(debugger_done_cond, mutex);

Also, I found a way to crash the old version I'd been using by accessing invalid memory addresses, but with the debugger not working I'm not able to test it on this build.

[edit] All I've managed to find is that pthread_cond_wait() is failing. SDL doesn't tell why. SDL_CreateCond() is working.

[edit again] I replaced the SDL_CondWait() with just setting rompause=1. It works on the title screen of Mario 64, but when the Mario head appears, it doesn't pause even though this flag is set. The pause button on the main window magically continues to work, but I see the "Mupen64Plus Started" text above the "Paused" text once the Mario head appears.

[more edit] Well I got that working by adding some more checks for rompause, then I accidentally hit a random key while trying to take this screenshot, and it proceeded to go into an endless loop complaining of SIGSEGV errors and popping up error messages until my X server locked up. >8^( (But I got it back under control by killing the process from SSH. Yay Linux!) I also reimplemented my fix for the buffer overflow in the FPU register display. (Those numbers get up to like 509 digits!) However SVN won't make a patch because "Directory 'mupen64_audio' is missing".

Unfortunately, there's another bug. See if you can figure out what's missing from this image.

[hey more editing] Yeah, if the core thread gets a SIGSEGV, it pops up message boxes in an infinite loop until the system locks up. V_v