Glide64 vs GCC. Need help

[Gonetz]

Could you explain me, how plugins are initialized under Linux? I need to start wxWidgets on dll load. For windows port it is done in DllMain function, which is automatically called when dll is loaded.

 

[smcd]

There are functions that you can use named _init and _fini that are called when loaded/unloaded for linux shared objects .so is that what you mean? The compiler attributes __attribute__((constructor)) and __attribute__((destructor)) might also be used but I'm not really familiar with those

 

[Gonetz]

I've reproduced DllMain behavior, and I see in my log file that wxWidgets initialization was successful, but plugin still crashes on load. I need to debug it. I'm not familiar with Linux IDE. Has anybody KDevelop or Anjuta project for MupenPlus version of Glide64?

 

[Funto]

If by "crash" you mean "segfault", you had better use the powerful tool that Valgrind is

 

[Gonetz]

I don't know, what happens. There are few error messages:

(process:2292): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.20.1/gobject/gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function

(process:2292): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(process:2292): Gdk-CRITICAL **: gdk_cursor_new_for_display: assertion `GDK_IS_DISPLAY (display)' failed

after which mupen loading hangs. I just want to run it in a debugger and get the call stack. So far I have no idea, where to dig.

 

[Funto]

If Mupen64Plus segfaults, Valgrind can give you the call stack (better if you compile with the -g option for debugging).

If you want to run it step by step in a debugger, personnaly I use GDB through the Code::Blocks IDE for this.

 

[Gonetz]

I fixed this particular issue. It was my bug.
Now I have to fight with wxWidgets issues - it crashes on some basic stuff.
I even managed to load the plugin with some hacks and get GUI working, but when I start a rom it crashes (segfaults) during some initialization routines. It seems that memory became corrupted, because it crashes where nothing wrong can be.

 

[Tillmann]

why don't you try to use gdb? Just run "gdb /pathtomupen/mupenplus64" and then start to use when it crashes look at the traceback output.

Simple and good debbuger (it will pinpoint problems with your plugin for sure)

 

[h4tred]

Sorry Gonetz about me being busy, I've been busy on a big reverse engineering project, as well as other things.

I even managed to load the plugin with some hacks and get GUI working, but when I start a rom it crashes (segfaults) during some initialization routines. It seems that memory became corrupted, because it crashes where nothing wrong can be.

Sure its purely a wrapper problem or a plugin problem? I know certainly the Unix VRAM detection code could do with tuning (since I did a completely non tested implementation)...could that mess with memory allocation perhaps?

 

[Gonetz]

I use Nemiver for debugging. It shows me the callstack, values of variables, but now I'm in the point, where I just can't understand, how segfault can happen in this place:
void debug_init ()
{
debug.capture = 0; <-- crashed on this line

 

[Gonetz]

Sure its purely a wrapper problem or a plugin problem?

I know only that it is crashed inside the plugin.

I know certainly the Unix VRAM detection code could do with tuning (since I did a completely non tested implementation)...could that mess with memory allocation perhaps?

Hmm, I may try to build the wrapper without VRAM detection code to be sure.

 

[Tillmann]

I use Nemiver for debugging. It shows me the callstack, values of variables, but now I'm in the point, where I just can't understand, how segfault can happen in this place:
void debug_init ()
{
debug.capture = 0; <-- crashed on this line

Well i've never used this program, but this output really do not says nothing at all (besides The init problem) maybe if you try gdb (pretty polished software) you could trace what is going on...

 

[Gonetz]

"Nemiver is an ongoing effort to write a standalone graphical debugger that
integrates well in the GNOME desktop environment. It currently features a
backend which uses the well known GNU Debugger gdb to debug C / C++
programs." That is, it is just gdb shell. Using pure gdb will give me nothing more.

 

[h4tred]

I know only that it is crashed inside the plugin.

Okay, I thought it was caused by something I did .

Hmm, I may try to build the wrapper without VRAM detection code to be sure.

I do intend though on completely testing out that SDL code with a test case I have, so that Unix code should be fixed when I get time. But I guess using a hardcoded value when your testing your port wouldn't hurt.

 

[Gonetz]

If by "crash" you mean "segfault", you had better use the powerful tool that Valgrind is

Is there any good front end for it? When just running valgrind mupenplus, it outputs to console, where it hard to read.

 

[Richard42]

Is there any good front end for it? When just running valgrind mupenplus, it outputs to console, where it hard to read.

Valgrind isn't an interactive tool like a debugger. The idea with Valgrind is that you can run it with "valgrind --leak-check=full ./mupen64plus" and then after you're done with the test case, look through the list of warnings and errors that it dumps out. It can dump the info out in XML format, and you can use a GUI front-end for parsing the XML and displaying it in a slightly more pretty format, but it's really not worth the trouble.

As far as debugger front-ends, DDD is an old X application that sits on top of GDB for debugging. It's not terribly pretty but it has a lot of features and works well.

 

[Gonetz]

MacOsX link error:

g++ -o glide3x.so -shared -lstdc++ combiner.o geometry.o main.o textures.o SDLMain.o -L"." -L"lib" -framework OpenGL `sdl-config --libs` --out-implib=libglide3x.a
Undefined symbols:
"_SDL_main", referenced from:
-[SDLMain applicationDidFinishLaunching:] in SDLMain.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [glide3x.so] Error 1

SDLMain.o is built from SDLMain.m for MacOs. Without it linker error is:
Undefined symbols:
"_SDL_main", referenced from:
-[SDLMain applicationDidFinishLaunching:] in libSDLmain.a(SDLMain.o)
ld: symbol(s) not found

What's wrong?

 

[Gonetz]

Found: the code must have int main(int argc, char*argv[]) procedure. I wonder, how you managed to compile the wrapper on MacOs without it?

 

[h4tred]

Not entirely sure in how MacOSX dynamic libs operate, sorry


http://developer.apple.com/DOCUMENTATION/DeveloperTools/gcc-4.0.1/gcc/Link-Options.html

Its funny: MacOSX's version of GCC does not support -shared.......

 

[Gonetz]

Found: the code must have int main(int argc, char*argv[]) procedure. I wonder, how you managed to compile the wrapper on MacOs without it?

!!!:angry:
Now I have:
ld: in ./lib/glide3x.so, can't link with a main executable