Debugger incoming!

Discuss topics related to development here.
Post Reply
User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Debugger incoming!

Post by MarathonMan » Thu Jan 15, 2015 5:46 pm

I sorely needed this to get compatibility and hunt down remaining bugs.

- Toggle-able and resizeable windows for a cutter-free, multi-monitor friendly debugging environment.
- Will expose all console state -- TLB mappings, pending DMAs, registers, disassembly, ...
- Qt 4.x (cross platform).
Attachments
cen64d.png
cen64d.png (335.29 KiB) Viewed 14621 times

User avatar
jaytheham
Posts: 9
Joined: Sat Nov 16, 2013 8:14 pm
Location: New Zealand
Contact:

Re: Debugger incoming!

Post by jaytheham » Thu Jan 15, 2015 6:02 pm

Sweet, I was just wondering about this the other day. Cen64 just keeps getting better and better

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: Debugger incoming!

Post by LuigiBlood » Thu Jan 15, 2015 6:29 pm

And with this I'll be able to finally find the problem in my 64DD emulation.

User avatar
Nacho
Posts: 66
Joined: Thu Nov 07, 2013 9:25 am

Re: Debugger incoming!

Post by Nacho » Thu Jan 15, 2015 8:19 pm

Is there a way to build it from the GIT (since I've already seen the uploaded files there :P)?

EDIT: Figured it out. qmake && make.
EDIT2: I was a bit overenthusiastic.... there's nothing functional... yet... :P coming soon.
Testing CEN64 on: Intel Core i5 520M 2.4 GHz. SSE2 SSE3 SSE4.1 SSE4.2 SSSE3, but no AVX. Ubuntu Linux

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Debugger incoming!

Post by MarathonMan » Fri Jan 16, 2015 6:01 pm

Starting to add more to the views. Hopefully ready to start populating the models soon.
Attachments
debug.png
debug.png (234.2 KiB) Viewed 14490 times

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: Debugger incoming!

Post by Narann » Fri Jan 16, 2015 7:31 pm

Impressive!

Would it be silly to ask for register "actual names" with maybe the value type they are storing?

Code: Select all

$r0 0x0000000F (int) 16
Or, for RDP:

Code: Select all

$r0 Dither Alpha enable (bool) True (0x00000001)
I ask this because RDP registers have a "real" meaning (key_en, antialias_en, dither_alpha_en z_compare_en z_update_en, etc...). Same for Video Interface (dither_filter_en, aa_mode, divot_en, gamma_en, gamma_dither_en, etc...).

I know the RDP and VI is not still written but from a N64 dev perspective it would be very easier to understand register meaning.

For the future of course! :)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Debugger incoming!

Post by MarathonMan » Fri Jan 16, 2015 9:57 pm

Yes, I plan to use meaningful masks for things like VR4300.CP0, RDP registers, etc. (along with a flat hex value in parenthesis next to it). I have not come up with a way that I am satisfied with to intuitively display this information yet, though... without cluttering the UI, anyways.

For general purpose registers, it does not make sense to assign a "type" with a register; this information is lost once a compiler lowers the AST to assembly. If we see some MIPS fragment like li $t0, 0x12345678, that value could either be a void * or a uint32_t; we don't know. Moreover, it could be used as a void * for one line of code, and reused for a uint32_t. Assembly is typeless!

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: Debugger incoming!

Post by Narann » Fri Jan 16, 2015 10:39 pm

MarathonMan wrote:Yes, I plan to use meaningful masks for things like VR4300.CP0, RDP registers, etc.
Great!
MarathonMan wrote:For general purpose registers, it does not make sense to assign a "type" with a register;
I agree. :)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Debugger incoming!

Post by MarathonMan » Sat Jan 17, 2015 11:24 pm

The windows builds for the debugger is now automated and on the frontpage/downloads.cen64.com.

Still not functional as of yet, though.

User avatar
Sintendo
Posts: 25
Joined: Thu Oct 31, 2013 9:11 am

Re: Debugger incoming!

Post by Sintendo » Sun Jan 18, 2015 5:14 am

Just a heads up, but I had to explicitly refresh the front page to see the new download link. I also had to do this when the downloads were first introduced.

Presence
Posts: 51
Joined: Fri Oct 18, 2013 9:27 am

Re: Debugger incoming!

Post by Presence » Sun Jan 18, 2015 12:30 pm

Looks good. Let me know if you need any help with the Qt portion.

By the way, I'm sure you're aware, but you can set Qt styles using qtconfig if you don't want to look at the ugly Redmond theme.

User avatar
teres
Posts: 19
Joined: Fri Apr 11, 2014 9:44 am

Re: Debugger incoming!

Post by teres » Sun Jan 18, 2015 12:35 pm

Sintendo wrote:Just a heads up, but I had to explicitly refresh the front page to see the new download link. I also had to do this when the downloads were first introduced.
Must be on your end (unless it got fixed recently because of your post), the headers regarding caching seem to be set correctly. Corporate proxy with an agressive caching policy to save some of those expensive, precious kilobytes, maybe? Or are you on mobile, where providers often do sth similar?

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Debugger incoming!

Post by MarathonMan » Sun Jan 18, 2015 2:02 pm

Presence wrote:Looks good. Let me know if you need any help with the Qt portion.
I'm becoming a big fan of Qt after trying it out.

Hardest part has been developing an intuitive, flexible network protocol.

User avatar
Sintendo
Posts: 25
Joined: Thu Oct 31, 2013 9:11 am

Re: Debugger incoming!

Post by Sintendo » Mon Jan 19, 2015 4:34 pm

teres wrote:Must be on your end (unless it got fixed recently because of your post), the headers regarding caching seem to be set correctly. Corporate proxy with an agressive caching policy to save some of those expensive, precious kilobytes, maybe? Or are you on mobile, where providers often do sth similar?
Neither scenario applies, AFAIK. It was with my home WiFi connection on a laptop.

User avatar
Breadwinka
Posts: 54
Joined: Fri Oct 04, 2013 11:35 pm

Re: Debugger incoming!

Post by Breadwinka » Mon Jan 19, 2015 5:38 pm

Sintendo wrote:
teres wrote:Must be on your end (unless it got fixed recently because of your post), the headers regarding caching seem to be set correctly. Corporate proxy with an agressive caching policy to save some of those expensive, precious kilobytes, maybe? Or are you on mobile, where providers often do sth similar?
Neither scenario applies, AFAIK. It was with my home WiFi connection on a laptop.
If your using chrome could be that, I know chrome loves to cache like a boss.

Presence
Posts: 51
Joined: Fri Oct 18, 2013 9:27 am

Re: Debugger incoming!

Post by Presence » Tue Jan 20, 2015 10:52 am

MarathonMan wrote:
Presence wrote:Looks good. Let me know if you need any help with the Qt portion.
I'm becoming a big fan of Qt after trying it out.

Hardest part has been developing an intuitive, flexible network protocol.
Yeah, Qt is easily my favorite cross-platform graphical framework. It does have a few downsides (the main one being it's large size), but it makes up for them with ease of use and its great documentation.

User avatar
Sintendo
Posts: 25
Joined: Thu Oct 31, 2013 9:11 am

Re: Debugger incoming!

Post by Sintendo » Wed Jan 21, 2015 6:03 pm

Breadwinka wrote:If your using chrome could be that, I know chrome loves to cache like a boss.
I was using Firefox at the time, though. The homepage doesn't change too often, so it's not a big deal. :)

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: Debugger incoming!

Post by beannaich » Wed Jan 21, 2015 10:38 pm

Breadwinka wrote:If your using chrome could be that, I know chrome loves to cache like a boss.
I had to actually implement cache busting at work to assist debugging JavaScript apps because of Chrome's caching. Its relentless.

User avatar
teres
Posts: 19
Joined: Fri Apr 11, 2014 9:44 am

Re: Debugger incoming!

Post by teres » Thu Jan 22, 2015 8:38 am

It's not Chrome, I use it too and don't see the issue, and it's been established he's on FF.
I'd say ignore it for now, at least until a second person with the same problem comes along. Then continue this discussion in a new thread.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: Debugger incoming!

Post by beannaich » Fri Jan 23, 2015 12:38 am

teres wrote:It's not Chrome, I use it too and don't see the issue, and it's been established he's on FF.
I'd say ignore it for now, at least until a second person with the same problem comes along. Then continue this discussion in a new thread.
Thanks for explaining to all of us how a forum works, Mr. 16 posts.

User avatar
teres
Posts: 19
Joined: Fri Apr 11, 2014 9:44 am

Re: Debugger incoming!

Post by teres » Fri Jan 23, 2015 11:16 am

beannaich wrote:Thanks for explaining to all of us how a forum works, Mr. 16 posts.
Oh so having a higher post count e-penis makes you be less of topic. Got it.

Also, plonk.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: Debugger incoming!

Post by beannaich » Fri Jan 23, 2015 8:26 pm

teres wrote:Oh so having a higher post count e-penis makes you be less of topic. Got it.
In the real world we call this "seniority". In addition to my higher post count, I've also been here longer, and contributed more to CEN64 than you. So yes, my e-peen is huge.

Anyways, back on point. Will the debugger ever go HLE on known RSP uCode? I think that might be kinda neat to see way down the road.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Debugger incoming!

Post by MarathonMan » Sat Jan 24, 2015 9:12 am

beannaich wrote:Anyways, back on point. Will the debugger ever go HLE on known RSP uCode? I think that might be kinda neat to see way down the road.
Zoinkity requested that you set breakpoints once known RSP ucode tasks get started. What do you mean by "go HLE on"?

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: Debugger incoming!

Post by beannaich » Sat Jan 24, 2015 2:28 pm

MarathonMan wrote:
beannaich wrote:Anyways, back on point. Will the debugger ever go HLE on known RSP uCode? I think that might be kinda neat to see way down the road.
Zoinkity requested that you set breakpoints once known RSP ucode tasks get started. What do you mean by "go HLE on"?
A view that decodes the memory into a higher level and displays the values of things such as voices, and mixers, etc. Currently the debugger plans seem to be to only support hardware I/O registers, CPU registers, pipelines. Something that could parse the memory and allow breakpoints on their values.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Debugger incoming!

Post by MarathonMan » Sat Jan 24, 2015 4:33 pm

Oh, I see. No, I don't have any plans for that at the moment. That'd be a lot of work.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: Debugger incoming!

Post by beannaich » Sat Jan 31, 2015 2:13 pm

MarathonMan wrote:Oh, I see. No, I don't have any plans for that at the moment. That'd be a lot of work.
It certainly would, but it wouldn't be that difficult to implement. Probably a good project for another dev :D

User avatar
MoochMcGee
Posts: 1
Joined: Fri Jul 17, 2015 8:48 pm

Re: Debugger incoming!

Post by MoochMcGee » Sun Jul 26, 2015 12:59 pm

I'm currently having a pretty huge problem with the debugger. It doesn't wait for CEN64 to start before claiming it's ready. In fact, it doesn't wait for anything. This makes it impossible to debug a single thing.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Debugger incoming!

Post by MarathonMan » Sun Jul 26, 2015 7:06 pm

Never finish hashing it out - it's still not functional.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests