Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: bootstrap on February 21, 2012, 05:17:38 am

Title: 64-bit register values and SIMD
Post by: bootstrap on February 21, 2012, 05:17:38 am
I'm writing and debugging 64-bit applications in both C and assembly language with the codeblocks IDE on ubuntu, but the registers only display 32-bits.  The IDE is smart enough to realize it is a 64-bit mode program, since it calls the registers "rax, rbx, rcx, rdx, rsi, rdi, rbp, rsp, r8, r9, r10, r11, r12, r13, r14, r15, rip...", BUT it only displays a 32-bit value for the contents of the registers.  The strange part is, the integer values seem to display values beyond the limit of 32-bit numbers, but the hexadecimal values never exceed 32-bit values... so I can't read addresses in registers!  Ouch!

Also, I'm writing a lot of SIMD assembly language now, complete with AVX and FMA4 and other up-to-date features... but the SIMD registers are not displayed!  That's a huge bummer.  Why are registers ymm0 ~ ymm15 missing?

Oh, one other extremely annoying aspect of the IDE is... the variables are not displayed in any obvious order.  They should be displayed in alphabetic order.  As it is now, it takes me FOREVER to find specific variables in large functions.  Very annoying!

Still, I love codeblocks... it's just missing a few very basic capabilities and features.
Title: Re: 64-bit register values and SIMD
Post by: MortenMacFly on February 21, 2012, 07:03:36 am
...version, platform please? Did you try the debugger branch?
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on February 21, 2012, 09:58:37 pm
...version, platform please? Did you try the debugger branch?

I think I have the latest binary build for "64-bit ubuntu 10.04 LTS".

When I select "help -> about" in the codeblocks IDE, it displays a dialog that says:

10.05

and underneath that it says in smaller text:

Build: May 27 2010, 11:01:42 - wx2.8.10 (Linux, unicode) - 64-bit.


What is a "debugger branch"?
Title: Re: 64-bit register values and SIMD
Post by: Alpha on February 22, 2012, 03:47:21 am
What is a "debugger branch"?
http://forums.codeblocks.org/index.php/topic,15947.0.html (http://forums.codeblocks.org/index.php/topic,15947.0.html)
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on February 23, 2012, 01:49:03 am
What is a "debugger branch"?
http://forums.codeblocks.org/index.php/topic,15947.0.html (http://forums.codeblocks.org/index.php/topic,15947.0.html)

This is all rather greek to me.  So let me ask this question (taken from the link you provided above).  To get newer updated versions of linux64 codeblocks periodically (nightly builds or something like that), I should put the following into my ubuntu64 /etc/apt/sources.list file:

deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg


Then when I update my system it will install the new version?  Or what?

PS:  I still don't know what a "debugger branch" is?  How is that different from the latest "nightly build"?
Title: Re: 64-bit register values and SIMD
Post by: Jenna on February 23, 2012, 06:32:44 am
What is a "debugger branch"?
http://forums.codeblocks.org/index.php/topic,15947.0.html (http://forums.codeblocks.org/index.php/topic,15947.0.html)

This is all rather greek to me.  So let me ask this question (taken from the link you provided above).  To get newer updated versions of linux64 codeblocks periodically (nightly builds or something like that), I should put the following into my ubuntu64 /etc/apt/sources.list file:

deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg


Then when I update my system it will install the new version?  Or what?
Yes, this should work.
Normally, my repo gets more often updated as the windows nightlies.
But you should also read the notes for ubuntu users on my server (http://apt.jenslody.de) .


PS:  I still don't know what a "debugger branch" is?  How is that different from the latest "nightly build"?
A branch with many new debugger features, that will be merged back into trunk in the (more or less) near future.
All other features are normally in sync with trunk.
Title: re: 64-bit register values and SIMD
Post by: bootstrap on February 23, 2012, 11:49:05 pm
Okay, I followed your instructions jens, and it did install svn7844 and wx2.8.12 and it does execute.

Unfortunately, I don't see that it fixed my problems.  Are my problems fixed yet and I don't see it (or need to select something somewhere), or are they not fixed?

PS:  The new version often doesn't display anything in the disassembly window when at a breakpoint while the old version did.  Is that a new bug?
Title: Re: 64-bit register values and SIMD
Post by: Jenna on February 24, 2012, 06:40:45 am
7844 is not the debugger branch, as you have written yourself (highlighting by me):
[...] I should put the following into my ubuntu64 /etc/apt/sources.list file:

deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg

[...]
you should not use the main, but the dbg section !
Revision for debugger-branch in my server is 7790 actuallly.
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on February 25, 2012, 04:35:16 am
7844 is not the debugger branch, as you have written yourself (highlighting by me):
[...] I should put the following into my ubuntu64 /etc/apt/sources.list file:

deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg

[...]
you should not use the main, but the dbg section !
Revision for debugger-branch in my server is 7790 actuallly.
Yikes, confusion!

Okay, I changed "any main" to "any dbg" in my /etc/apt/sources.list file and executed "sudo apt-get update".  That seemed to work, meaning it seemed to download and do its things, but when I run codeblocks it still runs the version I got yesterday (svn 7844).  Why is that?  Do I have two versions of codeblocks on my system somewhere?  A "find" command doesn't find anything that looks likely.
Title: Re: 64-bit register values and SIMD
Post by: Jenna on February 25, 2012, 09:03:58 am
apt-get update does not update the software, it only updates the package cache.
By the way, debugger-branch is now 7845.

You can try apt-get upgrade to update your system, but I recommend a package manager with a gui, like synaptic .
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on February 27, 2012, 09:06:39 am
apt-get update does not update the software, it only updates the package cache.
By the way, debugger-branch is now 7845.

You can try apt-get upgrade to update your system, but I recommend a package manager with a gui, like synaptic .

When I run codeblocks it says "svn7844" in the startup dialog and in the "help->about" dialog.

However, the register window still only displays 32-bit hexadecimal values for the registers, though the decimal values do reflect the full 64-bit values.  However, the decimal values aren't much use for looking for bits and bit-fields, or for displaying address ranges in memory.  Are you saying this SHOULD be fixed in svn7844, but I'm the only one it doesn't work for?

However, I still have the NEW problem that the disassembly window doesn't display anything when I "run to cursor" or "single step".  However, the disassembly window DOES fill up with contents when I "step into" a function.  I never had a problem with the disassembly window in the original vanilla 10.05 release.
Title: Re: 64-bit register values and SIMD
Post by: oBFusCATed on February 27, 2012, 09:19:56 am
If you have "Settings -> Debugger..." and "Debug->Active debuggers" menus then you have the debugger's branch version.

About the bugs:
1. Yes, it seems the cpu registers window uses 32 bit numbers for the hex values
2. You'll have to show a simple example code and the exact steps, so we can reproduce the disassembly problem. It seems to work correctly here.

Edit:
Code
Index: src/src/cpuregistersdlg.cpp
===================================================================
--- src/src/cpuregistersdlg.cpp (revision 7856)
+++ src/src/cpuregistersdlg.cpp (working copy)
@@ -66,7 +66,7 @@
     }
 
     wxString fmt;
-    fmt.Printf(_T("0x%x"), (size_t)value);
+    fmt.Printf(_T("0x%lx"), /*(size_t)*/value);
     m_pList->SetItem(idx, 1, fmt);
     fmt.Printf(_T("%lu"), value);
     m_pList->SetItem(idx, 2, fmt);

This patch seems to fix it, I've tried it on 64bit linux only.
Title: Re: 64-bit register values and SIMD
Post by: Jenna on February 27, 2012, 09:55:07 am
When I run codeblocks it says "svn7844" in the startup dialog and in the "help->about" dialog.
7844 is not the debugger branch, as you have written yourself (highlighting by me):
[...] I should put the following into my ubuntu64 /etc/apt/sources.list file:

deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg

[...]
you should not use the main, but the dbg section !
[...]
By the way, debugger-branch is now 7845.

But if I understand oBFusCATed correctly it does not work there at the moment.
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on February 27, 2012, 12:31:45 pm
Looks like now I can't figure out how to make ubuntu64 install the debug branch.  I *have* replaced those lines in the sources.list file and updated, but I guess I still have the main branch.  Is it now impossible to get the debug branch due to version numbering or something?

As for the disassembly window not showing contents, I generally start running with "run to cursor".

Another question.  Is it supposed to be possible to change register values while at a breakpoint?  I can't seem to find a way, but other debuggers I've seen (and written) allow that.

When I ran synaptic, I couldn't figure out how to get it to do anything sensible.  Any simpler ways that actually (horror) becoming expert at synaptic.
Title: Re: 64-bit register values and SIMD
Post by: oBFusCATed on February 27, 2012, 12:35:38 pm
As for the disassembly window not showing contents, I generally start running with "run to cursor".
Exact steps, please, but first make sure you have the debugger's branch. There were some fixes in regard to the disassembly.

Another question.  Is it supposed to be possible to change register values while at a breakpoint?  I can't seem to find a way, but other debuggers I've seen (and written) allow that.
In debugger's branch you can execute gdb commands, there is an entry box at the bottom of the debugger log.
Only you'll have to learn what are the exact gdb commands. I guess there is a room for improvement here :)
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on February 27, 2012, 01:05:58 pm
One more question.  Any way to view [and change] the xmm or ymm registers?
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on March 03, 2012, 11:28:26 am
Ehhhh, I hate to ask this, but perhaps I must.

What is the codeblock development process look like?  I mean, how many people are involved, how huge or small is the project, and how practical is it for me to start fixing things I want fixed?  I really, really, really don't want to do this, but at some point adding code to my programs to see 64-bit register contents, to change register contents at breakpoints, to view and change ymm registers when they exist... and other conveniences might become more cumulattive hassle and effort than fixing codeblocks.

On the plus side, I figure I have the required skill.  I've written complete IDEs before (editor, compiler, debugger, interactive graphicial GuiDesigner, etc), so more or less I've "been there, done that".

On the negative side, while I'm quick to invent and design, I'm much slower to interpret and learn from the work of others.  Which is probably why I tend to hate that kind of work.  OTOH, the fixes I have in mind are rather tiny in scope, so unless I'm required to add the fixes for every possible supported debugger or something similar, the fixes should be extremely localized.  Also on the negative side, I'm slow to learn new tools, so learning lots of new tools is necessary in practice, I should forget-about-it.

I guess there are other general practice issues that somebody should warn me about in advance.  I am super busy with my own projects, and can't justify working on codeblocks if I can't dive in and get results pretty quick.  And that depends to a great degree on what general practices the current developers may have.

Any advice along these lines?
Title: Re: 64-bit register values and SIMD
Post by: MortenMacFly on March 03, 2012, 12:44:30 pm
I mean, how many people are involved, how huge or small is the project, and how practical is it for me to start fixing things I want fixed?
http://developer.berlios.de/project/memberlist.php?group_id=5358
http://developer.berlios.de/patch/?group_id=5358

On the plus side, I figure I have the required skill.  I've written complete IDEs before (editor, compiler, debugger, interactive graphicial GuiDesigner, etc), so more or less I've "been there, done that".
Good to know. But in fact it shouldn't be too hard. Just make sure hat if what you want t do is related to the debugger, use the debugger branch and sync' yourself with oBFusCATed - he is the maintainer of that branch.
Title: Re: 64-bit register values and SIMD
Post by: oBFusCATed on March 03, 2012, 01:29:59 pm
This should be relatively easy thing to change, but it requires the change in the API.

cbCPURegistersDlg::SetRegisterValue supports only long int values, but probably the parameter's type should be wxString.
Also for the GUI I was thinking of using the wxGrid class instead of wxListCtrl, so one can edit the values of the registers.
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on March 04, 2012, 04:42:59 pm
Thanks for both replies.

I have a couple suggestions and more questions.

suggestion
Probably a significant percentage of programmers don't [purposely] program with xmm or ymm registers.  I assume most 32-bit mode programs don't pass arguments back and forth in xmm or ymm registers, so debugging most programs rarely involves the xmm or ymm registers.  So I suggest there be two separate register dialogs, one like the current register dialog, and another for xmm and ymm registers.

To be maximally helpful, the xmm and ymm register dialog needs to be much more complex than the regular register dialog.  Each ymm register can hold 32 s08/u08 variables, 16 s16/u16/f16 variables, 8 s32/u32/f32 variables, or 4 s64/u64/f64 variables.  That's 11 possibilities for each freaking register!

While it would be quite helpful sometimes, I don't think it is especially practical to display every register in all 11 ways --- much less let any of the 11 forms be edited to a new value (what if they edit two or three of them - which do we accept?).

I also think it is overkill to put 11 radio-buttons next to each register so each register can be displayed in the appropriate format.  That's just too complicated, especially since the appropriate display format changes from instruction to instruction during single-step.

So I guess a single set of 11 radio-buttons is best, that acts upon the format and display of every register.  At least it isn't too difficult to toggle back and forth and watch the contents to understand what's happening.  The biggest practical implementation problem here is that the number of active input fields needs to dynamically change between 32, 16, 8 and 4 per-register depending on the setting of those 11 radio buttons.

One simplification might be to only support 4 or 8 entries for each ymm register.  If someone needs to display 32 s08/u08 values, let them distinguish [and edit] 2-character subsets of the 32-bit 8-hex-digit hexadecimal displays.

Actually, the more I discuss this, the more obvious it seems that this xmm/ymm register dialog will be just too huge to dock in the IDE.  For practical purposes, it needs to be a separate floating dialog.  As such, it might as well contain 32 input/display widgets for each ymm register, and simply shrink-to-hide display/input fields that are irrelevant for the current radio-button selected format (s08/u08/s16/u16/f16/s32/u32/f32/s64/u64/f64).

I don't have any experience with wx widgets, so I have no idea how difficult it might be to create and operate such a dialog, with an array of 16 lines of 32 display/input fields that needs to resize each field whenever a new radio-button is selected.  But this seems the best approach off the top of my head.

One advantage of having only one set of radio buttons is... there is never any question how to interpret the input in any field.  Without having the radio buttons set in a specific state, the input "123" could be interpreted as any of these types: s08, u08, s16, u16, f16, s32, u32, f32, s64, 64, f64... or even a series of 8/16/32-bit characters!!!  Hopefully we can at least assume the input "123" is decimal and not hexadecimal for the lack of a leading "0x".  But is that assumption even reasonable if the display fields are current set to display in hexadecimal?

Any comments about how big a hassle such a dialog would be with wx widgets?  Off hand the wxGrid sounds more appropriate for this kind of situation (just based on the name, and nothing else).

And frankly, maybe even the regular register dialog should work in a similar manner.  Not sure.  At some point the complexity just becomes "too much" to support.  So maybe we should assume the regular registers only contain one value each (s64, u64, f64).  But the xmm/ymm registers have specific instructions to operate upon that whole range of types, so display and input in those many forms is appropriate in my opinion.

-----

As to the process, can someone list all the steps that I'd need to take to add a feature like this.  That will help me decide whether I can afford to take the time to dive in and get started.  Remember, I'm very fast and able at doing self-contained projects, even huge, complex, self-contained projects... BUT... I'm very slow to learn new tools.  Which is why, when I created my IDE/debugger application, I wrote everything from scratch.  No "dgb" to learn, no compiler to learn, no GUI-system to learn, nothing but my own compiler/editor/debugger/GUI-system to understand.  Which means, never any confusion about "how such-and-such works, or is implemented".  So please, give me a fully honest and realistic statement of steps and tools that I will face to start adding features to codeblocks.  Then I'll decide.

And "yes", as far as I can tell, the debugger is the part that needs the most work.
Title: Re: 64-bit register values and SIMD
Post by: oBFusCATed on March 04, 2012, 05:23:14 pm
1. Please do not add another dialog, the cpu registers dialog is just fine. Also keep in mind that the idea of the new API is to provide an abstraction, so it is possible to write different debugger plugins wrapping different debuggers, platforms, landuages.
2. The easiest thing to do is:
 - treat the value column of the registers as string
 - provide context menu with the following options: Format, Set, Copy Value
 - all this options will call into the debugger, so it can do its specific processing
3. The complexity depends on the goals you specify for yourself. It can take from 2-3 hours to months :)

p.s. please don't write such long posts
p.p.s. I don't know where do you work or live, but reading and understanding code written by others is more important than being the fastest developer on earth. So you have a chance to improve your skills in this area :)
p.p.p.s. I guess, I can spend some time to implement this simple scheme
Title: Re: 64-bit register values and SIMD
Post by: bootstrap on June 02, 2012, 06:55:51 am
p.p.p.s. I guess, I can spend some time to implement this simple scheme.

Did anything ever come of this?  If so, I'll install the latest nightly build.

Also, are you planning a 12.05 or 12.06 release?  I was guessing the 10.05 release was timed to follow the ubuntu 10.04 LTS release, which makes now a good time for a new general/binary release since ubuntu 12.04 LTS was released 1 month ago.
Title: Re: 64-bit register values and SIMD
Post by: oBFusCATed on June 02, 2012, 11:55:46 am
Did anything ever come of this?  If so, I'll install the latest nightly build.
No, unfortunately

Also, are you planning a 12.05 or 12.06 release?  I was guessing the 10.05 release was timed to follow the ubuntu 10.04 LTS release, which makes now a good time for a new general/binary release since ubuntu 12.04 LTS was released 1 month ago.
No, 12.05 went away. 12.06 is too close it time. Also there is no point in timing a release after a major distro release, if there was a timing it would have been 10.03 or 10.2.