* Setting breakpoint in src file located in different directory
@ 2005-04-12 10:16 Joakim Hove
2005-04-12 12:07 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Joakim Hove @ 2005-04-12 10:16 UTC (permalink / raw)
To: gdb
Hello,
I am running/debugging an executable in the path ~/RunPath
The executable in question is built from sources located in many
different directories. I (try) to set the breakpoints with the
~/.gdbinit file:
break /home/fimm/cmu/hove/libdos/src/ehist.c:694
break /home/fimm/cmu/hove/Cluster/Apps/src/Potts/Potts.c:396
This should in my opinion the breakpoints in the two files
listed. However when invoking gdb, I only get the message:
No source file named /home/fimm/cmu/hove/libdos/src/ehist.c.
No source file named /home/fimm/cmu/hove/Cluster/Apps/src/Potts/Potts.c.
I have also tried splitting it in two with:
directory /home/fimm/cmu/hove/libdos/src/
break ehist.c:694
directory /home/fimm/cmu/hove/Cluster/Apps/src/Potts/
break Potts.c:396
That succeeds for the file Potts.c (which is located in the directory
as the executable, i.e. the the executable is not located in the path
where gdb is invoked, gdb is invoked as:
%bash gdb ../exe
However the other file (ehist.c) still failed with the "No source file
named ..." message.
Any tips on how to resolve this would be greatly appreciated.
Joakim
--
Joakim Hove
hove AT ift uib no /
Tlf: +47 (55 5)8 27 90 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Setting breakpoint in src file located in different directory
2005-04-12 10:16 Setting breakpoint in src file located in different directory Joakim Hove
@ 2005-04-12 12:07 ` Daniel Jacobowitz
2005-04-12 12:18 ` Joakim Hove
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2005-04-12 12:07 UTC (permalink / raw)
To: Joakim Hove; +Cc: gdb
On Tue, Apr 12, 2005 at 11:16:56AM +0200, Joakim Hove wrote:
>
> Hello,
>
> I am running/debugging an executable in the path ~/RunPath
>
> The executable in question is built from sources located in many
> different directories. I (try) to set the breakpoints with the
> ~/.gdbinit file:
>
> break /home/fimm/cmu/hove/libdos/src/ehist.c:694
> break /home/fimm/cmu/hove/Cluster/Apps/src/Potts/Potts.c:396
>
> This should in my opinion the breakpoints in the two files
> listed. However when invoking gdb, I only get the message:
>
> No source file named /home/fimm/cmu/hove/libdos/src/ehist.c.
> No source file named /home/fimm/cmu/hove/Cluster/Apps/src/Potts/Potts.c.
You didn't mention what version of GDB you are using; that makes it
hard to help you. A lot of bugs in this area have been fixed lately,
so you might want to try 6.3 or a CVS snapshot.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Setting breakpoint in src file located in different directory
2005-04-12 12:07 ` Daniel Jacobowitz
@ 2005-04-12 12:18 ` Joakim Hove
2005-04-12 12:22 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Joakim Hove @ 2005-04-12 12:18 UTC (permalink / raw)
To: gdb
Thank you for answering!
> You didn't mention what version of GDB you are using; that makes it
> hard to help you.
Sorry:
bash% uname -a
Linux fimm.bccs.uib.no 2.4.21-27.0.2.ELsmp #1 SMP Mon Jan 31 12:44:32
CET 2005 x86_64 x86_64 x86_64 GNU/Linux
bash% gdb --version
GNU gdb Red Hat Linux (6.1post-1.20040607.17rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux".
> A lot of bugs in this area have been fixed lately, so you might want
> to try 6.3 or a CVS snapshot.
Does this indicate that the behaviour I describe was a bug? I was not
certain and thought maybe it was a feature; or otherwise that I was
going about in a wrong manner, I am quite new to gdb.
I don't have root access to the box in question, and would like to be
certain that the behaviour I described is fixed in the newest version
before I nag the system administrator / attempt an install in $HOME.
Best Regards
Joakim Hove
--
Joakim Hove
hove AT ift uib no /
Tlf: +47 (55 5)8 27 90 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Setting breakpoint in src file located in different directory
2005-04-12 12:18 ` Joakim Hove
@ 2005-04-12 12:22 ` Daniel Jacobowitz
2005-04-12 12:59 ` Joakim Hove
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2005-04-12 12:22 UTC (permalink / raw)
To: Joakim Hove; +Cc: gdb
On Tue, Apr 12, 2005 at 01:18:38PM +0200, Joakim Hove wrote:
> Does this indicate that the behaviour I describe was a bug? I was not
> certain and thought maybe it was a feature; or otherwise that I was
> going about in a wrong manner, I am quite new to gdb.
Yes, it is a bug.
> I don't have root access to the box in question, and would like to be
> certain that the behaviour I described is fixed in the newest version
> before I nag the system administrator / attempt an install in $HOME.
It will build and run fine from $HOME.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Setting breakpoint in src file located in different directory
2005-04-12 12:22 ` Daniel Jacobowitz
@ 2005-04-12 12:59 ` Joakim Hove
2005-04-12 13:04 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Joakim Hove @ 2005-04-12 12:59 UTC (permalink / raw)
To: gdb
Thanks again,
> Yes, it is a bug.
OK, very good I thought the behaviour I tried to achieve should be
valid.
> It will build and run fine from $HOME.
Well, that was indeed a no-brainer. I have now installed and run
version 6.3, however it does still not work (completely). Let me
describe in somewhat more detail how my configuration is:
o I have a directory ~/libdos/src/ which contains many different
source files. These files are compiled and linked to a shared
library.
o I have a directory ~/Apps/src which contains the src file "App.c"
for this particular application. This source is linked with the
shared library listed above to make an executable. The executable
"App.x" is left in this directory. The program runs as it should
(i.e. there are no problems loading the shared library.)
o I have a subdirectory ~/Apps/src/run from which the application is
run. So, when starting the application I do
bash% cd ~/Apps/src/run
bash% ../App.x
And this works fine.
o When trying to debug the application I invoke gdb as:
bash% ~/bin/gdb ../App.x
Regarding breakpoints from ./.gdbinit I get the following behaviour:
1: break /HOME/user/Apps/src/App.c:450
This corresponds to a situation where both the src file "App.c"
and the executable App.x are located in the same directory,
altough the execution is invoked from another directory. This
works in 6.3 and did not work in 6.1
2: break /HOME/user/libdos/src/ehist.c:450
This is an attempt to set breakpoints in one of the files which
are located in a "third" directory, i.e. distrinct from both the
directory containing the executable and the execution
directory. This fails with:
No source file named /home/fimm/cmu/hove/libdos/src/ehist.c.
3: If you to try set the breakpoint indicated in above manually from
within gdb I get the following behaviour:
bash% ~/bin/gdb ../App.x
<....>
(gdb) break /HOME/user/libdos/src/ehist.c:450
No source file named /home/fimm/cmu/hove/libdos/src/ehist.c.
Make breakpoint pending on future shared library load? (y or [n])
Well, answering yes to this and then starting the program with:
(gdb) run arg1 arg2 ...
Breakpoint 4 at 0x2a95673dd0: file ehist.c, line 450.
Pending breakpoint "/home/fimm/cmu/hove/libdos/src/ehist.c:450"
resolved
The pending breakpoint is immediately resolved, and everything
works correctly.
It seems that there is lesser acceptance for pending breakpoints from
the init file than from interactive definition. However, I do provide
exact coordinates in the init file, so that *should* in my opinion be
sufficient.
Anyway - Thanks
Joakim
--
Joakim Hove
hove AT ift uib no /
Tlf: +47 (55 5)8 27 90 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Setting breakpoint in src file located in different directory
2005-04-12 12:59 ` Joakim Hove
@ 2005-04-12 13:04 ` Daniel Jacobowitz
2005-04-12 13:16 ` Joakim Hove
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2005-04-12 13:04 UTC (permalink / raw)
To: Joakim Hove; +Cc: gdb
On Tue, Apr 12, 2005 at 01:59:46PM +0200, Joakim Hove wrote:
> o I have a directory ~/libdos/src/ which contains many different
> source files. These files are compiled and linked to a shared
> library.
That's the key. Shared library.
> 1: break /HOME/user/Apps/src/App.c:450
>
> This corresponds to a situation where both the src file "App.c"
> and the executable App.x are located in the same directory,
> altough the execution is invoked from another directory. This
> works in 6.3 and did not work in 6.1
Good. This is the bug which I thought was fixed.
> 2: break /HOME/user/libdos/src/ehist.c:450
>
> This is an attempt to set breakpoints in one of the files which
> are located in a "third" directory, i.e. distrinct from both the
> directory containing the executable and the execution
> directory. This fails with:
>
> No source file named /home/fimm/cmu/hove/libdos/src/ehist.c.
>
>
> 3: If you to try set the breakpoint indicated in above manually from
> within gdb I get the following behaviour:
>
> bash% ~/bin/gdb ../App.x
> <....>
> (gdb) break /HOME/user/libdos/src/ehist.c:450
>
> No source file named /home/fimm/cmu/hove/libdos/src/ehist.c.
> Make breakpoint pending on future shared library load? (y or [n])
>
> Well, answering yes to this and then starting the program with:
>
> (gdb) run arg1 arg2 ...
> Breakpoint 4 at 0x2a95673dd0: file ehist.c, line 450.
> Pending breakpoint "/home/fimm/cmu/hove/libdos/src/ehist.c:450"
> resolved
>
> The pending breakpoint is immediately resolved, and everything
> works correctly.
See the [n]? The default answer to this question is no, because
historically pending breakpoints were not available; this is the most
consistent interface. If you want this to work from .gdbinit, see
"help set breakpoint pending".
The breakpoint can't be set yet, because the shared library has not yet
been loaded.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Setting breakpoint in src file located in different directory
2005-04-12 13:04 ` Daniel Jacobowitz
@ 2005-04-12 13:16 ` Joakim Hove
0 siblings, 0 replies; 7+ messages in thread
From: Joakim Hove @ 2005-04-12 13:16 UTC (permalink / raw)
To: gdb
Daniel Jacobowitz <drow@false.org> writes:
> On Tue, Apr 12, 2005 at 01:59:46PM +0200, Joakim Hove wrote:
>> o I have a directory ~/libdos/src/ which contains many different
>> source files. These files are compiled and linked to a shared
>> library.
>
> That's the key. Shared library.
OK - sorry for being late with that information.
> [...] If you want this to work from .gdbinit, see "help set
> breakpoint pending".
"set breakpoint pending on"
at the top of .gdbinit did the trick.
Thank you very much for your help.
Best Regards
Joakim Hove
--
Joakim Hove
hove AT ift uib no /
Tlf: +47 (55 5)8 27 90 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-04-12 13:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-12 10:16 Setting breakpoint in src file located in different directory Joakim Hove
2005-04-12 12:07 ` Daniel Jacobowitz
2005-04-12 12:18 ` Joakim Hove
2005-04-12 12:22 ` Daniel Jacobowitz
2005-04-12 12:59 ` Joakim Hove
2005-04-12 13:04 ` Daniel Jacobowitz
2005-04-12 13:16 ` Joakim Hove
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox