Re: [cdt-dev] Fwd:Nacl-gdb and eclipse cdt integration

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

On Tue, Jul 6, 2010 at 8:59 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
> It would be nice to make life easier for those people.
>
>> 1) set the path to sel_ldr as the "C/C++ Application" on the main tab
>> of the debug configuration dialog
>
> This seems to require user input to know the proper path for that
> developer's env

Yes, that's required for built as well. For example, with the Android
integration, I created a preference for the root location for the SDK
install. Under there all the tools are in a well known path and passed
to the environment when running the build and now when running the
debugger. That should be sufficient.

>> 2) add any arguments you want to pass to sel_ldr (-d is implied when
>> you start under gdb) and your nexe on the arguments tap
>
> Here too.

This is essentially what the CDebugger extension is. I did this for
the MinGW debugger where I automatically put the full path to the
debugger in place when the user selected that debugger.

>> 3) create a command file to tell gdb to load your nexe. Mine only has
>> 1 line, e.g:
>> nacl-file hw.nexe
>
> I guess this could be unified with the second part of point 2) and
> we could tell gdb to load the file automatically.
>
>> 4) on the debugger tab, set the path to nacl64-gdb in the "GDB
>> debugger" field and your file in the "GDB command file" field
>
> If we could automatically put the string 'nacl64-gdb' instead
> of 'gdb'.  Could be done by solving
> Bug 120162 Allow to specify the default version of gdb
>
> I guess the value of some support for this is to avoid the user
> having to do point 3).
>
> It probably wouldn't be too hard to have an extension point
> like you suggest (I'm not sure what you guys did for the
> managed build).  However, would the user have to define the entire
> gdb startup sequence, which is not trivial, our would the user
> simply add certain launch commands, like for Harware debugging.
> The tricky thing for the latter may be to know the proper place
> to run those extra commands, during our launch sequence.

I guess what I am really thinking about is a CDebugger type thing,
possibly more focused on launching than the actual debugger interface.
And maybe even focused exclusively on gdb. The cases I'm seeing is
really just the need to run commands at start up in a certain order as
well as launching the right gdb executable.

Let's give it some thought and I can spend a little time on it once
I'm back from holidays which end this week.

Thanks Marc,
Doug.