[Lazarus] Fpdebug merge request 6

[Martin Frb]

On 05/09/2021 21:08, Martin Frb wrote:
> 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....


> 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>