[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