Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] specifying "GDB Command File" in Debugger tab of Debug Configurations dialog

 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
> Sent: Thursday, July 29, 2010 6:11 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] specifying "GDB Command File" in 
> Debugger tab of Debug Configurations dialog
> 
[...]
> 	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? 

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. 

I believe so.
But you can probably do even better.  See below.

> 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. :-)

That is how I had imagined it originally, when you explained
your svn setup.  But now that I see a slighlty more complex
project structure, I'm thinking it would be possible for you
to have a gdbinit file (you can name it anything you want)
inside each of the SubProjects.
Then, you would make each .launch file either:
1- have "GDB command file" be SubProjectX/<gdbinit file name>
or
2- have the Arguments tab point the working dir to 
${workspace_loc:<project_name>}/SubProjectX

#2 may make sense for other reasons, where you want to treat
your SubProjects as the main location for execution.

> 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?

The patch is very simple and should apply cleanly to the 7.0 branch.

> Thanks a bunch!

No problem, it helped find a bug :-)

> 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
> 	
> 
> 
> 

Back to the top