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