View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0037838||Lazarus||Debugger||public||2020-09-29 14:54||2020-09-29 17:00|
|Reporter||Klaus1||Assigned To||Martin Friebe|
|Summary||0037838: When I will see the RAW value from the vector register I see only zeros|
|Description||When 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 Information||Hello 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.
|Tags||No tags attached.|
|Fixed in Revision|
Registerdlg.7z (7,796 bytes)
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 https://github.com/User4martin/lazarus
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.
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)
|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|