Setting up Eclipse for Wii Development

First up, not 100% sure which forum this should be in, but since the other discussion was in here...

The first complete draft of my Eclipse Wii Dev guide is live and I need some more interested users to give it a shot before I move it to a main page.
Any hiccups that users come across, any feedback whatsoever, I want to hear about.
Oh, and places in the process where a screenshot or two would be particularly helpful.

Cheers guys.



Edited 1 time(s). Last edit at 06/06/2009 03:37PM by PhoenixTank.

Awesome, I will be sure to go through with it tomorrow. Thanks especially for the instructions on wifi debugging setup, it probably would have taken me a while to figure out as I'm sure it took you some time. I just made a short addition; for editing the PATH variable, I've found a program recently that splits it up into separate entries for you. I hope you don't mind. [wiibrew.org]

Thanks again for the nice guide, should be very handy. You should probably also consider adding the bit on wifi debugging to the main debugging page, or at least as much as you can add without talking about eclipse specifically.

A lot of the work was just piecing together info.
That path programs sounds like a useful addition, too.
I'll consider adding a link to the wifi debugging, from the main debugging guide. The version is mostly non specific at the moment, so it shouldn't be a problem, but having the full text and keeping it up to date in two places would annoy me.
Make sure you let me know how it all goes.



Edited 1 time(s). Last edit at 06/06/2009 03:36PM by PhoenixTank.

OK, I'm going through it right now. One thing I just noticed is that you have one thing that could be done a little bit better in the makefile part. You mentioned that it's a good idea to add the command make before using wiiload, which is sensible but slightly inefficient. If you just add a dependency to the run target, like the following:

run: $(OUTPUT).dol
	wiiload $(TARGET).dol

the run target will depend on the $(OUTPUT).dol target, which is a little more efficient I think than spawning a second copy of make.

Edit: I'm a bit confused by this part:

Quote

Commands tab
* If you are not using an external gdb command file, "Initialize" should contain your "target" command, and if you did not specify a path to your project .elf in the C/C++ on the main tab, a "symbol-file" command.

What should the target command be for wifi debugging? And I assume the symbol-file command is supposed to refer to the elf file, but what should it be explicitly?

I'd also like to point out that TortoiseSVN is a pretty nice SVN client for Windows, and I usually prefer it for stuff that doesn't directly relate to eclipse, like downloading the libogc source. It has a nice tool for applying the wifi patch easily, although I've never tried with Eclipse so I don't know how easy that is. I just find that it's usually faster to use TortoiseSVN than eclipse, although I use subversive instead of subclipse, but I don't really know why. I used to use subclipse but then subversive became an eclipse project or whatever so I figured it should have better integration or something. It's a bit annoying to use and every now and then the update site would get screwy for me, but that's probably not relevant since it feels like every now and then the eclipse update manager decides to crap out and die for me.

Ah, I see you did provide a target command later in the guide, but perhaps it would have been nice to have it earlier.

Hmm, so I think I've gone through it, but I haven't tested debugging yet. Will do so tomorrow, I've been very tired today. As for a GDB tutorial, I find that the manual is pretty good, and as for a project wizard, I was thinking about doing that. Hopefully tomorrow or Monday I'll get around to figuring out how that works.



Edited 4 time(s). Last edit at 06/07/2009 08:29AM by iofthestorm.

Quote
iofthestorm
OK, I'm going through it right now. One thing I just noticed is that you have one thing that could be done a little bit better in the makefile part. You mentioned that it's a good idea to add the command make before using wiiload, which is sensible but slightly inefficient. If you just add a dependency to the run target, like the following:

run: $(OUTPUT).dol
	wiiload $(TARGET).dol

the run target will depend on the $(OUTPUT).dol target, which is a little more efficient I think than spawning a second copy of make.

I'm no makefile guru, and I can see the idea is sound, but it doesn't seem to do anything useful here.

make run 
linking ... HelloWorld.elf
c:/devkitpro/devkitppc/bin/../lib/gcc/powerpc-gekko/4.2.4/../../../../powerpc-gekko/lib/crtmain.o: In function `__crtmain':
e:/projects/devkitPro/buildscripts/newlib-1.17.0/libgloss/rs6000/crtmain.c:18: undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [/c/WiiDev/projects/HelloWorld/HelloWorld.elf] Error 1

Having another make instance doesn't seem particularly slow. For the helloworld example, it is practically instant. For something as large as libogc (already compiled), make only takes a few seconds here, inside a VM.
If you can figure out what needs to happen to fix that for the example makefile, it'd be a great addition, but I can't really search around for a solution, atm.

Scratch that...

run: $(BUILD) 
	wiiload $(TARGET).dol

Seems to work correctly. Is that what you intended?

Quote
iofthestorm
Edit: I'm a bit confused by this part:

Quote

Commands tab
* If you are not using an external gdb command file, "Initialize" should contain your "target" command, and if you did not specify a path to your project .elf in the C/C++ on the main tab, a "symbol-file" command.

What should the target command be for wifi debugging? And I assume the symbol-file command is supposed to refer to the elf file, but what should it be explicitly?

Ah, I see you did provide a target command later in the guide, but perhaps it would have been nice to have it earlier.

The idea was to have the generic setup, then split off between USB Gecko & Wifi Debugging. It could probably use a bit of reorganising, though. I'll see what I can do.

Quote
iofthestorm
I'd also like to point out that TortoiseSVN is a pretty nice SVN client for Windows, and I usually prefer it for stuff that doesn't directly relate to eclipse, like downloading the libogc source. It has a nice tool for applying the wifi patch easily, although I've never tried with Eclipse so I don't know how easy that is. I just find that it's usually faster to use TortoiseSVN than eclipse, although I use subversive instead of subclipse, but I don't really know why. I used to use subclipse but then subversive became an eclipse project or whatever so I figured it should have better integration or something. It's a bit annoying to use and every now and then the update site would get screwy for me, but that's probably not relevant since it feels like every now and then the eclipse update manager decides to crap out and die for me.

TortoiseSVN isn't bad, and I use it myself when I just want to check out a copy of something for a snoop around. I personally kinda like having the libogc source on hand quickly, from Eclipse, though. I just added Subclipse as a minor info titbit, really.
Oh and applying a patch is as easy as right clicking the project and heading to Team > Apply Patch. You can do that with any Eclipse project, I think.

Quote
iofthestorm
Hmm, so I think I've gone through it, but I haven't tested debugging yet. Will do so tomorrow, I've been very tired today. As for a GDB tutorial, I find that the manual is pretty good, and as for a project wizard, I was thinking about doing that. Hopefully tomorrow or Monday I'll get around to figuring out how that works.

Thanks for your help! I think Arasium was considering creating a project wizard plugin, but all I know is that the docs are a little outdated and I haven't touched Java yet =)

Quote
PhoenixTank
Scratch that...

run: $(BUILD) 
	wiiload $(TARGET).dol

Seems to work correctly. Is that what you intended?

Yeah, that's what I intended I guess. It's not really going to be noticeably faster, just I feel that it's a more "correct" way to do things, since dependencies are the essence of makefiles more or less.

Quote
PhoenixTank
The idea was to have the generic setup, then split off between USB Gecko & Wifi Debugging. It could probably use a bit of reorganising, though. I'll see what I can do.

Oh OK, that makes sense. Maybe just put in a note about the fact that the actual command comes in later, since I've never used gdb remotely so I had no idea what to put in there.

Quote
PhoenixTank
TortoiseSVN isn't bad, and I use it myself when I just want to check out a copy of something for a snoop around. I personally kinda like having the libogc source on hand quickly, from Eclipse, though. I just added Subclipse as a minor info titbit, really.
Oh and applying a patch is as easy as right clicking the project and heading to Team > Apply Patch. You can do that with any Eclipse project, I think.

Oh hey! Actually, that does sound handy. I'll probably check it out in eclipse then. You might want to add a note about how to apply the patch, since I've never actually used a patch file before and my first instinct was to drop to the command line and figure that out, which might have been a more time consuming endeavor. Luckily I happened to right click on the patch file and saw the option to apply the patch.

Quote
PhoenixTank
Thanks for your help! I think Arasium was considering creating a project wizard plugin, but all I know is that the docs are a little outdated and I haven't touched Java yet =)

Hmm, well, we can probably help each other if he posts here about his progress. I've actually been having trouble just finding the right docs, although I keep seeing them mentioned in mailing list posts. But I should be able to figure it out eventually, and I'm on summer break so I have plenty of time to do so. And thanks for making the guide, I would have had no idea to look up Zylin. I don't actually use eclipse for C much, mostly for Java, so I haven't really messed with the CDT side of things too much.

Mmm, so I think this is the proper help file, and it seems to have not been updated since Eclipse 3.3/CDT4.0, but it should probably be fine. It seems like it's probably more work than I would have anticipated, and feels a little annoying, but hopefully it shouldn't be too bad.



Edited 1 time(s). Last edit at 06/08/2009 12:05AM by iofthestorm.

Yes, I've take a look to create a plugin and it's very difficult :) The documentation is so useless :) For the moment, i'm using a template but it doesn't works on Vista (perhaps eclispe still have some problems with Vista)..

You have forgotten some important points in your article. The first is that you need tu use the -oO option a the compilation and no -o1 or -o2 ....

Then, your library (if you use some personal libraries) needs tu use the -o0 option too.

And to finish, I think you can speak about the binary parser. The elf will be considered as a binary only if you choose a good binary parser. I think, the elf parser is selected by default in the projet options, but the better way is to select the "GNU elf parser" and replace the "c++filt" and "addr2line" of the GNU tools by the one used with the wii ("powerpc-gekko...") like you did with the gdb.

Hmm, it seems like as I was trying to duplicate the wifi patch on my laptop, the libogc SVN fell into a state where it no longer builds for me. In addition, the elf that I was able to compile before with the wifi debugging patch didn't seem to work. Could you let me know which revision from SVN you were able to apply the patch to? The latest ones don't seem to be working.

Actually, I think my laptop is being stupid. I'll figure it out later.



Edited 1 time(s). Last edit at 06/13/2009 03:03AM by iofthestorm.

Been out of action for a few days (myself and my computer), but finally managed to get on here again.
Made some changes as per the thread and reorganised a little. Thanks for the tip on the binary parser, Arasium. The guide does instruct you to use -O0, though.
Just recompiled with the latest SVN & patch applied, iofthestorm; worked fine though I didn't test beyond a compile.

Huh, I am an idiot. Apparently I hadn't rebuilt my dol after adding the debug stuff, so I just had a basic hello world file that wouldn't respond to gdb at all. After rebulding it works fine, and I can use the eclipse debugger. Awesome! Apparently there are two threads by default? That's interesting.

I, do you have a problem when gdb stop? Me, muy eclipse alway bugging and i've an alert window (i close it and all is ok, but i want to avoid this alert).

I've read that you install Zylin! Me i use the classic CDT debugger. So, do you use the Zylin debug tools or the CDT classic debug tools?

Hmm, I seem to have problems with using wifi while debugging, although maybe that's not quite the problem. I also installed Zylin per PhoenixTank's guide, but I'm not sure what advantage it has.

Oh, by the way, does debugging over wifi do anything for you when you hit a code dump? I was under the impression that if you were connected via USBGecko you would get more information, but is it possible that if debugging via wifi your debugger gets disconnected?



Edited 1 time(s). Last edit at 06/18/2009 08:23PM by iofthestorm.

My debugger doesn't disconnect very well. Sometimes, i've to kill the gdb process!!
And when i've a code dump, i can't do anything debugging over wifi!

As far as I am aware, there is no built in remote debugger for C/C++ in Eclipse, hence the use of the Zylin plug-in.
If that is not the case, do let me know... but it doesn't seem to be a part of the default CDT install.
Essentially, the set up is the Zylin plug in, using the CDT debugger GUI.
Yeah, I have had to kill the GDB process many times. Try using "detach"... works somewhat well.
Noticed that the gdb can't talk to the app if in an infinite while loop.

@iofthestorm
Not hit a code dump while debugging, in honesty. I'll try to find out if my USB Gecko handles it better, and I expect it would.

Like it says in the guide, the wifi patch is the poor man's usb gecko ;)

Oh nice, you got a USB Gecko. So gdb can't set a breakpoint while the program is looping to stop the loop? I guess that makes sense, although I would hope that the scheduler would preempt the main thread every now and then to check the debugging thread, or however it works.

Yeap, it was an impulse buy.
Something like that. All I know is that I have a libwiigui based app; debugs without issues up until it is waiting for user input, and then is unresponsive. I guess it is just a case of adding a break point within that loop.
I think I remember it being less of an issue if you "stepped in" until that point as opposed to using "cont" or the GUI's resume.. Not sure if that is just a wifi patch issue or not.

Ok, so now (in eclipse 3.4) there is a remote debugger with the CDT. I haven't install Zylin and it works (except when i want to detach the debugger).

I can configure it in "local application" debug. There is a drop down list to choose the debug method. We can use the Gdbserver one nd it works.

Quote
iofthestorm
Apparently there are two threads by default? That's interesting.

The second thread is the idle thread for when all threads on the queue are locked.

Quote
arasium
Ok, so now (in eclipse 3.4) there is a remote debugger with the CDT. I haven't install Zylin and it works (except when i want to detach the debugger).

I can configure it in "local application" debug. There is a drop down list to choose the debug method. We can use the Gdbserver one nd it works.

Ah-ha! I spent far too long looking for something like that. Nice to know it is there, but I still actually prefer the Zylin plug-in. Why on Earth is it under "Local Application"? :| That baffles me.

Quote
PhoenixTank
Ah-ha! I spent far too long looking for something like that. Nice to know it is there, but I still actually prefer the Zylin plug-in. Why on Earth is it under "Local Application"? :| That baffles me.

Lol, yes, it takes me some time to find where this option were in eclipse. The use of "Local Application" isn't appropriate :) I will take a look to Zylin, because, the classic debugger still have some problems (the watchers aren't very good).