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

> For future reference, when I have bug feedback like this, is it sufficient to post to the cdt-dev thread, or should I post to the associated bug page(s), or both?
 
Normally, once a bug is opened, the discussion should be in the bug only.  That way, only interested people will be getting the updates.
 
Thanks for confirming it worked.
 
marc
 

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
Sent: Friday, July 30, 2010 1:51 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] specifying "GDB Command File" in Debugger tab of Debug Configurations dialog

I'm using the 7.0 date tag, not the branch, but your patch was simple enough to apply to the tag as well. I have exported the result it works as expected. In the gdb traces console I now see the 'environment-cd' command happen earlier, and it cd's into the project root. So I can specify .gdbinit files relative to this path and get per-launcher .gdbinits. It works.  :-)

For future reference, when I have bug feedback like this, is it sufficient to post to the cdt-dev thread, or should I post to the associated bug page(s), or both?

T

On Fri, Jul 30, 2010 at 8:05 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: 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
>
>
>
> _______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top