How does one restrict displayed registers in debugger?

[b]

Since SlickEdit supports a native GDB, I'm back to using the IDE to debug.  However, I've run into one display issue that is driving me crazy.

It appears that when one has the registers window open, it attempts an enumeration of every possible register, and after single instruction stepping, it resets the window back to the top.  However, the registers of interest are v0 and v1, which are at the bottom.  Is there a way to tell SE not to display registers that are 'Unknown'?

[Dennis]

Click on the "Name" column, you should be able to reverse the sort order.

We just display the registers that GDB gives us.  As far as I know, GDB doesn't have an option to filter that down to the relevant ones per-context.  I could file a feature request to add filtering by name to the Registers dialog.

[b]

Click on the "Name" column, you should be able to reverse the sort order.

We just display the registers that GDB gives us.  As far as I know, GDB doesn't have an option to filter that down to the relevant ones per-context.  I could file a feature request to add filtering by name to the Registers dialog.

That is odd as I resorted to using gdb-multiarch on a Linux box to old school debug this issue and it does not show all these extra registers that SE reports. 

[Dennis]

Well, the first thing you have to understand.  We use GDB's MI interface.

There's no guarantee that you'll get the same answer from the equivelent MI command as the GDB CLI command.  Someone could have massaged the CLI command to filter out less relevant registers, and done nothing with the MI implementation (or not documented it).

[b]

Well, the first thing you have to understand.  We use GDB's MI interface.

There's no guarantee that you'll get the same answer from the equivelent MI command as the GDB CLI command.  Someone could have massaged the CLI command to filter out less relevant registers, and done nothing with the MI implementation (or not documented it).

I suspect as much.  A means of filtering out the Unknown variables would make the display of the registers in SE more useful. 

[Dennis]

I didn't even notice that there were a bunch of registered named "Unknown".

Oh, if only GDB didn't insist on reporting garbage...

And yes, "info registers" supports stuff that the MI command -data-list-register-names" doesn't support.

So, those extra registers are apparently floating point or vector registers which for whatever reason, GDB does not have names for. 

I can add some code for v23 to just skip those unnamed registers.

10.13 Registers
You can refer to machine register contents, in expressions, as variables with names starting with ‘$’. The names of registers are different for each machine; use info registers to see the names used on your machine.

info registers
Print the names and values of all registers except floating-point and vector registers (in the selected stack frame).

info all-registers
Print the names and values of all registers, including floating-point and vector registers (in the selected stack frame).

[jporkkahtc]

The register names would be part of the architecture specific code in GDB.

If you grab the GDB source code you will find it has *.c/*.h files for each supported CPU/architecture. The register names are part of this CPU specific code (I forget exactly how this is configured).

Are you doing remote debugging?
Maybe there is some inconsistency between the remote GDB server and your local GDB client? Could be that the GDB server is reporting registers that your GDB client doesn't know about?

[b]

Yes, I am doing remote debugging (of sorts).  I'm connecting to a Segger JLink with JTAG to my embedded board.  The JLink provides gdbserver functionality so I can use any gdb compliant tool an not be limited to the proprietary vendor of the part (e.g., Microchip and their MPLABX/ICD3).  If I use my Linux host's gdb-multiarch, I get the registers just fine as gdb is, itself doing the translation.  However, as discussed, if I use SE and let it use its gdb, the MI it supplies to SE apparently is not as nice as what I get from the command line (of which Dennis can elaborate).

So, if I use gdb directly, I get mostly what I want (I just don't get the nice GUI that SE provides with all the niceties of tool tip look ups and the like).  Moreover, the registers window, which was the complaint in this thread, shows a plethora of 'Unknown' registers before getting to the main system registers v0 and v1 (which alphabetically sort *after* the 'Unknown').  Worse, if I scroll down to view just the registers I want (v0 and v1), every time I step, the window refresh causes the register window to scroll back to the top (thus I lose focus of the registers I want to watch).

I wanted the gdb aspect as I'm debugging the bootloader that loads an app and want the ability to change the symbol table on the fly as I leave the bootloader and start executing the dynamically loaded app (that Microchip doesn't provide--unless the app is statically built with the bootloader).   With SE I can (re)attach the remote process with the local elf file and debug (first the bootloader's elf file and then reattach with the app's).

[jporkkahtc]

So you need a build of GDB multiarch for your PC, and use that instead of GDB supplied by Slick.

Ideally, GDB supplied by slick would be built this way, though it is considerably larger than a single target GDB.

Are you running slick on linux?
If so, just configure slick to use your multiarch gdb that you already have.

[b]

No, slick's gdb already supports mips just fine.  As Dennis described, the problem is with how gdb sends back information via the machine format to slickedit to process.  Dennis can correct me, but as I understand it, a new gdb wouldn't solve the problem with SE.   The gdb machine interface (https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html) and gdb interactive user interface are two different things.

Before spelunking into gdb's interpreter code, I would presume that the interpreter front end simply drops unnamed entriesI can see the grief as using the Linux gdb-multiarch and executing it in MI, it does return empty register info:

Code: [Select]

(gdb)
-data-list-register-names
^done,register-names=["","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","zero","at","v0","v1","a0","a1","a2","a3","t0","t1","t2","t3","t4","t5","t6","t7","s0","s1","s2","s3","s4","s5","s6","s7","t8","t9","k0","k1","gp","sp","s8","ra","status","lo","hi","badvaddr","cause","pc","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9","f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20","f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31","fcsr","fir","","","","","","","",""]
(gdb)

I presume if I were to spelunk the gdb user interface, it discards the unnamed entries.

Side note to Dennis's earlier comment.  I see by this output that the floating point registers are dumped correctly and that SE does, in fact show these.  It's all of the unnamed ones that SE shows, but gdb's interactive interface strips out.

Another comment, it would be nice to see the registers sorted numerically such that it doesn't list them as

Code: [Select]

..
f0
f1
f10
f11
..
f2
f30
f31
f4
f5
..