Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joakim Hove <hove@ift.uib.no>
To: gdb@sources.redhat.com
Subject: Re: Setting breakpoint in src file located in different directory
Date: Tue, 12 Apr 2005 12:59:00 -0000	[thread overview]
Message-ID: <bjj8y3o2ojx.fsf@termo1.fi.uib.no> (raw)
In-Reply-To: <20050412122148.GA7954@nevyn.them.org> (Daniel Jacobowitz's message of "Tue, 12 Apr 2005 08:21:48 -0400")

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


  reply	other threads:[~2005-04-12 12:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-12 10:16 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 [this message]
2005-04-12 13:04         ` Daniel Jacobowitz
2005-04-12 13:16           ` Joakim Hove

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bjj8y3o2ojx.fsf@termo1.fi.uib.no \
    --to=hove@ift.uib.no \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox