<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 05/09/2021 21:08, Martin Frb wrote:<br>
</div>
<blockquote type="cite"
cite="mid:89d18870-bf01-9f9a-363f-67fbe04bf627@mfriebe.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 05/09/2021 20:57, Christo Crause
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGOmfbHrzoT2hC6Nh4mdgG_aKDLNcZR=-HT8g_Amvw9TQ5+5WQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<div> <br>
1) adding to the IDE options. Looks that then every
user using fpdebug, will see options for host/port? <br>
While really convenient for avr users, rather
confusing for others?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
</blockquote>
Ok, so on the topic of user config.<br>
<br>
Step 1 is to decide, if IDE-config for avr debugging should be
part of the generic FpDebug config.<br>
<br>
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.<br>
That would mean to subclass TFpDebugDebugger and add a new
TFpRemoteDebugDebuggerProperties or TFpAvrDebugDebuggerProperties.<br>
<br>
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.<br>
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).<br>
<br>
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)<br>
<br>
Since it seems you agree, I will base below points on this....<br>
<br>
<br>
<blockquote type="cite"
cite="mid:89d18870-bf01-9f9a-363f-67fbe04bf627@mfriebe.de"> There
are 2 ways here:<br>
<br>
1) find a way to pass a custom config to whatever
T[avr]DbgProcess.<br>
<br>
2) Instantiate a process class, before starting the controller,
and push that in.<br>
That also has the advantage that it allows to choose between
several process classes, if more than one can handle the target.<br>
</blockquote>
<br>
*** Option 1<br>
<br>
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.<br>
Then you could set any config values to it, that you would want.<br>
<br>
But the controller should keep control of calling either
StartInstance or AttachToInstance => which currently call the
constructor.<br>
<br>
StartInstance/AttachToInstance would become normal methods.<br>
And the constructor would be called before them.<br>
<br>
In that case you could <br>
- create the instance of your TDbgAvrProcess outside of the
controller, <br>
- set host/port/... to the instance,<br>
- and pass it to the controller before calling Run.<br>
<br>
This also needs to ensure, that the OsDbgClasses are matching the
instance<br>
Some sample of how they can be set:
<a class="moz-txt-link-freetext" href="https://gitlab.com/martin_frb/lazarus/-/tree/f-fpdebug-override-OsDbgClass-selection">https://gitlab.com/martin_frb/lazarus/-/tree/f-fpdebug-override-OsDbgClass-selection</a><br>
That can be easily extended to pass the TDbgAvrProcess instance too.<br>
<br>
The controller then just calls StartInstance/AttachToInstance .<br>
<br>
<br>
*** Option 2<br>
<br>
have a <br>
TDbgProcessConfig class and a TDbgAvrProcessConfig subclass.<br>
That can be instantiated.<br>
And host/port/... can be copied to it.<br>
<br>
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.<br>
<br>
Of course that also modifies StartInstance/AttachToInstance.<br>
So it seems of little benefit to me.<br>
<br>
*** Option 2a<br>
If StartInstance/AttachToInstance become normal methods, and the
constructor is called before, then the controller could do:<br>
MainProcess := OSDbgClasses.DbgProcessClass.create;<br>
MainProcess.Options := ....<br>
MainProcess.StartIntstance(....);<br>
<br>
That would mean you would not need to pre-select the OSDbgClasses.
(But still could)<br>
<br>
<br>
<br>
IMHO 1 or 2a.<br>
<br>
Your opinion?<br>
</body>
</html>