View Issue Details

IDProjectCategoryView StatusLast Update
0037838LazarusDebuggerpublic2020-09-29 17:00
ReporterKlaus1 Assigned ToMartin Friebe  
Status feedbackResolutionopen 
Product Version2.0.10 
Summary0037838: When I will see the RAW value from the vector register I see only zeros
DescriptionWhen I will see the RAW value from the vector register I see only zeros. In the old releases I see the RAW values
of the vector registers.
I have seen in debugger window the output of the GDB, this is only as decimal value. I think the debugger need
print /x $register or better info all-registers -> Raw value
Additional InformationHello Martin,
I have here a develop for the registerdlg. In the zip file is the develop and a description in text file.
It is a other display with diffrent output for the vector registers, but need the RAW vector value.
Regards Klaus
TagsNo tags attached.
Fixed in Revision
Attached Files



2020-09-29 14:54


Registerdlg.7z (7,796 bytes)

Martin Friebe

2020-09-29 16:45

manager   ~0125960

Last edited: 2020-09-29 17:00

View 2 revisions

First of all: Please supply patches/diff (and ideally against svn trunk).
Your file appears to be based on one of the releases. If I compare it I see your changes mixed with the undoing of any changes that exist in trunk.

Alternatively, for this particular issue you may also submit pull requests on
For other issues, pull requests must be pre-agreed.

Unfortunately the change you want has to be implemented in a different way.

From a very quick glance at your code, you are parsing the gdb text, and reformat it. But that assumes that gdb is the only backend.
Lazarus also uses lldb and fpdebug. (fpdebug does not yet display those registers, but once it does, the format may be different / I have not tested lldb in respect to this matter).

Further more you are putting CPU dependent knowledge into the register dialog. People also debug other CPU (cross debugging / fpdebug-avr). Those cpu may have other special registers.
That is not to say, that CPU dependent code may not end up in the IDE, if different back-ends supply information in a common format (probably not text based), but that would still require the backend to indicate the type of data (as opposed to gleaning this from a name).

Currently all other formatting is done in the backend. I.e. gdb is used to convert between decimal and hex. That is equally very wrong.

However until this is fixed, the backend also needs to be responsible for supplying the correct format for *mm registers.
The gdb backend could use your parsing code, and supply the correct "raw" formatted text.

line 2005
function TGDBMIDebuggerCommandRegisterUpdate.DoExecute: Boolean;

This could either issue extra gdb commands, or it could parse the result of the current command, and re-format it.

On the long term, the entire front-end (registers, watches, locals,...) need major rework.
This will include rework of the DebuggerIntf, to allow refining the responsibilities of the backend and the IDE.
This can be discussed outside this issue (I.e., forum)

Issue History

Date Modified Username Field Change
2020-09-29 14:54 Klaus1 New Issue
2020-09-29 14:54 Klaus1 Status new => assigned
2020-09-29 14:54 Klaus1 Assigned To => Martin Friebe
2020-09-29 14:54 Klaus1 File Added: Registerdlg.7z
2020-09-29 16:45 Martin Friebe Note Added: 0125960
2020-09-29 16:45 Martin Friebe Status assigned => feedback
2020-09-29 16:45 Martin Friebe LazTarget => -
2020-09-29 17:00 Martin Friebe Note Edited: 0125960 View Revisions