Martin Frb wrote 14 lines
On 05/09/2021 20:57, Christo Crause wrote:
>
>
> 1) adding to the IDE options. Looks that then every user using
> fpdebug, will see options for host/port?
> While really convenient for avr users, rather confusing for others?
>
>
> I am starting to agree with this view. There are quite a few extra
> remote options that should eventually be implemented, so the IDE
> options will become more busy. My simplistic view is that a new
> remote Lazarus debugger will inherit just about all its core
> functionality from the existing FpDebugDebugger, with added remote
> config options.
Ok, so on the topic of user config.
Step 1 is to decide, if IDE-config for avr debugging should be part of the generic FpDebug config.
At current, I see that as a remote debugger, and therefore would think it should be made a separate entry in the list of debuggers. That would mean to subclass TFpDebugDebugger and add a new TFpRemoteDebugDebuggerProperties or TFpAvrDebugDebuggerProperties.
Of course, it may turn out in the future that the current config will get a bit of a mix. Lets say if support for Win on Arm would be added, and some options are arm/intel specific.
Or if some options are Windows/Linux specific. (Like loading debug symbols for Windows dll, that can be downloaded at MS / not planned by the way).
But I still think remote debugging is a step further. (To say, it could even be that we get an fpdebug remote / actually there also is Joost's DAB debugger)
Since it seems you agree, I will base below points on this....
Show quoted text 8 lines
There are 2 ways here:
1) find a way to pass a custom config to whatever T[avr]DbgProcess.
2) Instantiate a process class, before starting the controller, and
push that in.
That also has the advantage that it allows to choose between several
process classes, if more than one can handle the target.
*** Option 1
Initially my thought was that once you have a TFpAvrDebugDebugger you could just instantiate the TDbgAvrProcess before starting the debugger, and pass the instance to the TDbgController.
Then you could set any config values to it, that you would want.
But the controller should keep control of calling either StartInstance or AttachToInstance => which currently call the constructor.
StartInstance/AttachToInstance would become normal methods. And the constructor would be called before them.
In that case you could
- create the instance of your TDbgAvrProcess outside of the controller,
- set host/port/... to the instance,
- and pass it to the controller before calling Run.
This also needs to ensure, that the OsDbgClasses are matching the instance Some sample of how they can be set:
https://gitlab.com/martin_frb/lazarus/-/tree/f-fpdebug-override-OsDbgClass-selection That can be easily extended to pass the TDbgAvrProcess instance too.
The controller then just calls StartInstance/AttachToInstance .
*** Option 2
have a
TDbgProcessConfig class and a TDbgAvrProcessConfig subclass. That can be instantiated.
And host/port/... can be copied to it.
It can be passed to the controller before calling Run, and it can then be passed to the constructor. Or to StartInstance/AttachToInstance as an optional argument.
Of course that also modifies StartInstance/AttachToInstance. So it seems of little benefit to me.
*** Option 2a
If StartInstance/AttachToInstance become normal methods, and the
constructor is called before, then the controller could do:
MainProcess := OSDbgClasses.DbgProcessClass.create;
MainProcess.Options := ....
MainProcess.StartIntstance(....);
That would mean you would not need to pre-select the OSDbgClasses. (But still could)
IMHO 1 or 2a.
Your opinion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210914/f8be273b/attachment.html>
