[Lazarus] Switching debugger based on Project settings for embedded targets
Martin Frb
lazarus at mfriebe.de
Wed Nov 21 00:07:58 CET 2018
On 20/11/2018 22:44, Michael Ring via lazarus wrote:
> There is only one issue I see at the moment, the debugger is a global
> setting, afaik I cannot change the debugger configuration based on a
> project.
>
> The problem is that for debugging arm I will have to use
> arm-none-eabi-gdb, for pic32 I will have to use mips-sde-elf-gdb for
> debugging and both will have to use a special debugger class for
> interfacing with Segger JLink Debug Probe and possibly openocd in the
> future.
>
> Other people, that use Lazaeus for Windows/Linux/Mac Development would
> also need to change the global setting when switching from embedded
> development to native development to the default gdb debugger.
>
> What is the best way to implement this project based override, I guess
> I can do the coding myself as I have also created my own debugger for
> JLink, but I do not know how to do this debugger switching in the
> proper 'Lazarus' way.....
Indeed an issue that several people raised....
Well first of all, it depends on how much work you want to spent. There
are several approaches possible.
Just some initial thoughts, ideas are welcome...
* All of them should really refactor the "debugger setting" related
stuff from the big TEnvironmentOptions class into its own class, so that
it can be re-used as needed.
Some details are more than what would be really required to have a
working version. Up to you how far you want to go.
(I got a bit carried away while typing)
1) Have an override in the project. All the settings can be stored there
too.
That may require duplication of the frontend, so the project options can
show the same setting page.
Not my favourite (and not sure if the least work)
2) Expand the TEnvironmentOptions, so they can have a list of named
options. The project then chooses by name/ID (for each buildmode).
- That just adds a name dropdown / add/del button to the existing config.
- The config must then be stored like the units in the project lpi, each
config in a different path.
The current path <CONFIG> <EnvironmentOptions> <Debugger ...> would
then be replaced by <CONFIG> <EnvironmentOptions> <Debuggers>
<Debugger1 name="" ...>
The EnvOptsVersion would be increased so code knows what to load.
The DebugManager would ask the TEnvironmentOptions via
TEnvironmentOptions.GetDebuggerConfByName(name) and get the
refactored/extracted object that holds all the debugger setting. So
outside the TEnvironmentOptions changes will be minimal. (Hopefully)
- Name or ID could be used. This has an impact when projects are shared
between people.
It needs some additional thought what to do, if a name/id is not found.
Also names have the issue, that the same name, does not guarantee the
same settings.
ID could be UUID, but then you would never have the correct settings
for some one else's project. And you cant change the UUID in the lpi (or
the other person has a problem), so you must create the same ID in your
TEnvironmentOptions....,
Maybe storing (in the lpi) a name, with DebuggerType/Class (eg GDBMI)
and optional an ID. Then if you do not have the ID, you can import it,
to any of your configs (so each config in TEnvironmentOptions can have
many IDs)
- Optional/Later: there could be an option where to save the setting
EnvironmentOptions/project.lpi/project.lps
But it would still be the TEnvironmentOptions responsibility to
coordinate everything.
Note that some setting, like Ignored-Exceptions are already on the
project. They do not need to be affected.
3)
Your idea?
-----------------
I like the 2nd, but please bring forward any thoughts you have.
Let me know your ideas, and what you think is plausible for you to do,
and we can look at implementation details.
*** Also despite me bringing forward various options, not all of them
will be required. ***
*** E.g you could deliver a working version using just a name list in
EnvironmentOptions. And a name in the project. Thats afaik the minimum
needed ***
More information about the Lazarus
mailing list