Re: [cdt-dev] specifying "GDB Command File" in Debugger tab of Debug Co

[Tim Black <timblaktu@xxxxxxxxx>]

Looks like I was wrong about GDB's working directory.
After trying a couple of things, what I see is that for DSF-GDB,
GDB starts off by using the directory in which you started
eclipse.  In your case, it seems you started eclipse
from /home/tblack.  So, this is where gdb will
expect to find the .gdbinit file.

That's right. I was using a shortcut to start eclipse, and pwd seems to default to ~. I restarted eclipse from the command line and now I can see pwd is the location of the eclipse executable. And yes I agree that locating .gdbinit being dependent on where eclipse was started from is a bad thing and should be changed. Good work!
 

Note that we then change the working directory, using
-environment-cd, based on what is specified in the launch
Arguments tab.

CDI does it a little bit differently and effectively sets
the working directory first, then reads .gdbinit.

This may be a bug in DSF-GDB.  I'm not sure what
is the best thing to do, but if we want to do what CDI
does, we should first use -environment-cd then do
source .gdbinit.  (It cracks me up that we may already
have to re-order the FinalLaunchSequence, if you've
been following that discussion :-))

I have been following it from a distance, given my lack of experience with the implementation of the eclipse launching framework. Let's just say I've been following it enough to appreciate the need for comic relief!
 

Based on my latest findings, after fixing the bug I just wrote,
the .gdbinit file could be part of the project for which the launch
applies, since that is the default value in the Arguments tab.
If I understand correctly, this will actually be very nice for
your setup, no?  You can check-in the .gdbinit inside each project.

When you say 'project' here, you mean Eclipse project, i.e. with a one-to-one correspondence to a .cproject file, right? We have several launchers within a single Eclipse project, so this isn't exactly what I was requesting. However, if I am understanding you correctly, it does achieve the most important part of my request which was to be able to share the .gdbinit file in svn without requiring users to manually copy it to some special location. So let's say we have a single eclipse project with multiple executables and corresponding .launch files. The structure would be like this:

MyProject/
MyProject/.project
MyProject/.cproject
MyProject/.gdbinit
MyProject/makefile
MyProject/ExecutableA
MyProject/ExecutableA.launch
MyProject/source/

MyProject/SubProject1/makefile
MyProject/SubProject1/Executable1
MyProject/SubProject1/Executable1.launch
MyProject/SubProject1/source/

MyProject/SubProject2/makefile
MyProject/SubProject2/Executable2
MyProject/SubProject2/Executable2.launch
MyProject/SubProject2/source/

The .gdbinit file would reside at the top level of a project and each .launch within defines "GDB Command File" as ".gdbinit" (the default). This .gdbinit file would be found because your patch will change the behavior of launch sequence so that we cd into the project root (something like ${workspace_loc:<project_name>}) before doing "source .gdbinit". There's no need to ever change the value of "GDB Command File" from the default unless you want to define a separate gdb init for only a specific launcher. That'll float my boat, yes. :-)

Regarding your patch, I'd be happy to test this for you, but I have a question first. it looks like you committed it to HEAD and 7.0 branch. My current Eclipse build process is based on the 7.0 release tag (v201006141710). As you will recall, I did this to ease the application of the pretty-printer bug patch last week. Given this information, would you recommend a method for applying this new patch? Do you think this patch will apply successfully to the June 14 code base I have now, or do you think there are dependencies requiring the 7.0 branch or HEAD?

Thanks a bunch!
Tim

 

> On Thu, Jul 29, 2010 at 6:13 AM, Marc Khouzam
> <marc.khouzam@xxxxxxxxxxxx> wrote:
>
>
>       > -----Original Message-----
>       > From: cdt-dev-bounces@xxxxxxxxxxx
>       > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
>       > Sent: Tuesday, July 27, 2010 7:30 PM
>       > To: CDT General developers list.
>       > Subject: [cdt-dev] specifying "GDB Command File" in Debugger
>       > tab of Debug Configurations dialog
>       >
>       > I need to know what is the PATH that CDT (or gdb?) uses to
>       > look up the "GDB Command File" setting in the Debugger tab of
>       > the Debugger Configurations dialog?
>
>
>       There is no path used by CDT.  We simply pass the text in the
>       "GDB command file" text box, to gdb.  CDI specifies this text
>       when starting gdb using --command, while DSF-GDB sends a
>       'source <file>' command.
>
>
>       > I want to share a .gdbinit file with my team for use in C/C++
>       > debug launchers, so I don't want the launcher file to contain
>       > absolute paths. But I noticed that when I set the "GDB
>       > Command File" setting to ~/.gdbinit, the corresponding
>       > .launch file changes the value of
>       > org.eclipse.cdt.debug.mi.core.GDB_INIT and
>       > org.eclipse.cdt.dsf.gdb.GDB_INIT to "/home/tblack/.gdbinit".
>
>
>       I didn't see this myself.  I saw ~/.gdbinit in the launch file.
>
>       FYI, org.eclipse.cdt.debug.mi.core.GDB_INIT is used by CDI while
>       org.eclipse.cdt.dsf.gdb.GDB_INIT is used by DSF-GDB.
>       We probably should unify them (and many others) but it hasn't
>       been important enough for anyone to take the time.
>
>
>       > But I noticed that when I change the "GDB Command File"
>       > setting to ".gdbinit", the corresponding .launch file leaves
>       > the value of org.eclipse.cdt.debug.mi.core.GDB_INIT as
>       > "/home/tblack/.gdbinit", but changes
>       > org.eclipse.cdt.dsf.gdb.GDB_INIT to ".gdbinit". Why does one
>       > expand to absolute path and the other not? In this example I
>       > have only one .gdbinit on my system and it is in /home/tblack
>
>
>       Assuming you are using DSF-GDB, when you change the file name,
>       only org.eclipse.cdt.dsf.gdb.GDB_INIT will change,
>       org.eclipse.cdt.debug.mi.core.GDB_INIT will not be changed since
>       it only applies to CDI.  This is most probably why you still
>       saw it as it was before.
>
>
>       > We use shared .launch files. I'm prepared to make the
>       > simplification that each user has one global .gdbinit file
>       > that they use for debugging all C/C++ projects. This is
>       > because I'd rather not have to create a duplicate .gdbinit
>       > file for each .launch.
>
>
>       I don't understand what you want to be able to do.
>       Do you want one .gdbinit file for all your team, or do you
>       want each user to have her own, while still using the same
>       .launch file?
>
>       Also, where is your gdb?  If it can be anywhere as based
>       on the PATH variable, then not using absolute path for .gdbinit
>       may be difficult.  If you can't predict where gdb will be run
>       from, then choosing a .gdbinit file relative to that
> unpredictable
>       path won't work.
>
>       Marc
>       _______________________________________________
>       cdt-dev mailing list
>       cdt-dev@xxxxxxxxxxx
>       https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
> _______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev