zmm-reg in debug?

[TreeLibrarian]

I'm wondering what it would take to get the zmm register contents displayed in the debug CPU-registers window?

I'd be prepared to do the work myself if someone could point me at the right source files, and maybe a list of build-deps (debian/ubuntu) ... I've been rummaging in the debuggergdb folder but not finding it.

I do my vector optimization with hand-coded nasm routines in a C framework, which all works nicely thanks to the custom build options, but debugging is a hassle when I can't see the register contents and only have k-reg results to go on... or I have to insert a call to dump all the registers to memory every other instruction...

As an aside, the lexers for asm files are a bit muddled, since the 68000 asm lexer takes precedence over the x86 (masm) lexer for lexing of .asm files. This had me confused for a long time as the asm files were being recognized, but the lexer wasn't recognizing most of the instructions or registers. As a temporary I reassigned the masm lexer to .nasm file extensions, but then because the masm lexer is so out-of-date I made a new lexer file for nasm with (nearly) all of the newer (AVX,BMI,avx512) instructions and registers, so I'd at least have a spellcheck for the instructions.

I'd happily share if anyone's interested, but be warned it's only 98% complete and may have errors still.

[stahta01]

IIRC, the zmm-reg problem is in GDB; so, test gdb does it work from the command line! If not, the go to a website that supports gdb to ask for help!

Edit2: Add link https://forums.codeblocks.org/index.php/topic,25615.msg174324.html#msg174324

Edit3: I think this is the upstream project that lexer changes apply to https://www.scintilla.org/Lexilla.html
I could be wrong.

Tim S.

[TreeLibrarian]

Thanks, I'll look into gdb see how it is there...

Edit3: I think this is the upstream project that lexer changes apply to https://www.scintilla.org/Lexilla.html
I could be wrong.

Tim S.

There's a 2-layered thing with the lexers, there's the lexer code C library that does the primary parsing that comes from Lexilla, but there's also the xml language definition files containing all the keywords, file extensions, comment characters etc. that can easily be edited or copied that seem to be mainly part of C::B. (eg. there's no masm asm definition, or 68k definition in the Lexilla repo as far as I could find, they both use the same asm lexer code). I've made a new xml based on the existing masm xml file, and edited others so it all works better. I do think the asm lexer itself could do with a bit of an upgrade, if only to allow diverse meaningful coloration of instructions (like by avx version or by execution port), but that is something to aim at the lexilla project.

[TreeLibrarian]

IIRC, the zmm-reg problem is in GDB; so, test gdb does it work from the command line! If not, the go to a website that supports gdb to ask for help!

Tim S.

running "info vector" as a user command in C::B while debugging dumps all the zmm-registers + mxcsr into the debug log tab in C::B, so I don't think there's an issue with gdb, it's just not implemented in C::B.

Would be nice to be able to choose which interpretations of the registers will be displayed on a register-by-register basis (suggest byte/word/dword/qword/f16/f32/f64 hex/dec and right-to-left/left-to-right element ordering as options)...

Does anyone know where the registers window is being updated in the C::B source?

[Miguel Gimenez]

The panel inside the dialog is created in cpuregistersdlg.cpp, you can access it via DebuggerManager::GetCPURegistersDialog()

Updating is done by GdbCmd_InfoRegisters::ParseOutput() or GdbCmd_InfoRegisters::ParseOutputFromOR32gdbPort() in gdb_command.h, every register matching the reRegisters regex (in gdb_commands.h) should be shown.

[TreeLibrarian]

The panel inside the dialog is created in cpuregistersdlg.cpp, you can access it via DebuggerManager::GetCPURegistersDialog()

Updating is done by GdbCmd_InfoRegisters::ParseOutput() or GdbCmd_InfoRegisters::ParseOutputFromOR32gdbPort() in gdb_command.h, every register matching the reRegisters regex (in gdb_commands.h) should be shown.

OK, got it. Thanks 

so the simple solution is just to change the "info registers" command to gdb to "info all-registers"...
...except that gdb spits out unusably much info (every possible interpretation of the register, all on one line) and I think the regex would get very confused since it's only intended to get 2 hex values per line...

so my second thought is to convert the data sent by "info vector" down to just the v8int64 version, convert to a uint64_t[] to send to the dialog, from which it can reinterpret-cast the data to whatever type is selected. (the float data interpretations given by gdb aren't actually as float text anyway, but as hex with "repeated 15 times" if they're all the same). converting to text should be done on the fly according to the selected interpretation ... that said, I'm not sure this is possible for a wxListCtrl's list items.

A simpler option would be to have 3 interpretations on 3 lines for each register: right-to-left hex (with appropriate visual division) covers all integer interpretations, then float and double, also right-to-left to align with the hex.

Any opinions?

[Miguel Gimenez]

You can create a regex similar to this

Code

([xyz]*mm[0-9]+)[[:blank:]]+(.*)

and try to match it before the current one. If it matches, send register name (match[1]) and whatever you want from match[2] to the list control.

The mxcsr register will be accepted by the current regex.

I do not know if sending all registers will penalty debugging performance too much, in this case a setting would be a must.