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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
> Sent: Thursday, July 29, 2010 1:38 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] specifying "GDB Command File" in 
> Debugger tab of Debug Configurations dialog
> 
> Thanks Marc. I'm using DSF only, so you explained why I'm 
> seeing only one of the variables change in the .launch file. Also,
> 
> tblack@lenny:~$ which gdb
> /usr/bin/gdb
> 
> In my environment, I am seeing that CWD is /home/tblack after 
> eclipse has called gdb. I put "import os; print os.getcwd()" 
> in ~/.gdbinit and I see this in my "gdb traces" console:
> 
> 600,874 (gdb) 
> 601,004 3source .gdbinit
> 601,007 &"source .gdbinit\n"
> 601,018 ~"/home/tblack\n"
> 601,089 3^done

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.

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 :-))
My first thought is that being dependent on where eclipse
was started is a bad thing.
I've just opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=321259
about it.

Note also that you can use the 'pwd' command in GDB to check
(from .gdbinit or at any other time, what the working directory is).

> We are using svn metaprojects to tie together all required 
> component projects for a master product project. So we put 
> .project, .cproject, and top-level makefile at the top of the 
> metaproject so all users have to do is check out the 
> metaproject to disk and Import... "existing projects from 
> workspace", or better yet, Import... "Checkout projects from 
> SVN" using Subclipse. We are sharing .launch files in svn, 
> and each is located in the root of each make-able subproject. 
> So when users import the eclipse project, eclipse 
> auto-detects the .launch files and presents them in Debug 
> Configurations... with all the right settings.
> 
> Of course, one of these settings is "GDB Command File", yet 
> another file to share, and I was just trying to figure out 
> the best way to do so. My main goal is to prevent team 
> members from having to manually create it or having to modify 
> the launcher. It seems that the commands we want in .gdbinit 
> will be the same for all or most launchers, so I was 
> considering putting a single shared .gdbinit file in svn and 
> asking users to export it into their ~/. I am pretty sure 
> this will just work. (BTW, I am now seeing "~/.gdbinit" in my 
> .launch file. Sorry for the confusion. I think when I posted 
> before I must have had /home/tblack/.gdbinit in "GDB Command File"..)'

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.

> Then I started to think that a better way to manage it would 
> be to colocate a .gdbinit with each .launch file. This way, 
> users don't have to do anything but checkout the metaproject 
> and they're done. Also, this way we can customize .gdbinit on 
> a per-debug-launcher basis which may come in handy. So I was 
> just trying to gain some insight that would help me point the 
> launcher to a .gdbinit in the same dir as the .launch without 
> using an absolute path.

Looks like you'll get your wish, but per project.  Good enough?

> The only way I can do what I want to do here would be if 
> (a) GDB was somehow started with cwd = the path of the .launch or
> (b) a new eclipse environment variable equal to the location 
> of the .launch could be evaluated and passed into "GDB 
> Command File" string
> 
> I'm guessing neither of these are possible, so I'll just have 
> to stick with the one-.gdbinit-in-~/ solution.
> 
> T
> 
> 
> 
> 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
> 	
> 
> 
>