Re: [Lazarus] Fpdebug merge request 6

[Martin Frb via lazarus]

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?
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fpdebug merge request 6

[Martin Frb via lazarus]

On 05/09/2021 20:57, Christo Crause wrote:


On Sun, Sep 5, 2021 at 8:24 PM Martin Frb via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


I ve seen it. I am really rather busy ...


No worries, I do realise there are a lot of changes to work through.

I had a look at the first 2 or 3 commits some weeks ago.
From what I recall

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.


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.





2) global vars (iirc for host/port)
That is due to the lack of config that can be passed in

FpDebug (package) can not see the IDE conf. FpDebug should have
minimum package depenencies.
It needs its own conf that can be passed
I have some ideas there, 


Will gladly await your ideas.  This can wait, it is just a bad 
practise on my side currently, but workable.


(2) above would deal with this.



-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fpdebug merge request 6

[Christo Crause via lazarus]

On Sun, Sep 5, 2021 at 8:24 PM Martin Frb via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> I ve seen it. I am really rather busy ...
>

No worries, I do realise there are a lot of changes to work through.


> I had a look at the first 2 or 3 commits some weeks ago.
> From what I recall
>
> 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.

2) global vars (iirc for host/port)
> That is due to the lack of config that can be passed in
>
> FpDebug (package) can not see the IDE conf. FpDebug should have minimum
> package depenencies.
> It needs its own conf that can be passed
> I have some ideas there, 
>

Will gladly await your ideas.  This can wait, it is just a bad practise on
my side currently, but workable.


> -
> The rest I have not yet looked at, sorry.
>

No problem, as long as it is still on your radar!
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fpdebug merge request 6

[Martin Frb via lazarus]

I ve seen it. I am really rather busy ...

I had a look at the first 2 or 3 commits some weeks ago.
From what I recall

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?


2) global vars (iirc for host/port)
That is due to the lack of config that can be passed in

FpDebug (package) can not see the IDE conf. FpDebug should have minimum 
package depenencies.

It needs its own conf that can be passed
I have some ideas there, 

-
The rest I have not yet looked at, sorry.


On 05/09/2021 08:44, Christo Crause via lazarus wrote:
I'm busy adding xtensa/esp32 support to fpdebug, which builds on top 
of the AVR support.  It would be helpful if the AVR merge request[1] 
for fpdebug gets reviewed, since the current xtensa work builds on top 
of this (with some refactoring).


Best wishes,
Christo

1. 
https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/6 






-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus