This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: trouble locating source files through relative paths


On Wed, Aug 24, 2005 at 04:53:57PM +1000, Craig Jeffree wrote:
> On Tue, 2005-08-23 at 07:40 -0400, Bob Rossi wrote:
> > I'll look into this.
> 
> It looks like find_and_open_source() could be modified to check if
> dirname is relative and if so call openp with dirname prepended to
> filename instead of modifying the search path.
> 
> I think this is what Dave Korn suggested earlier, except he proposes
> identifying the relative link before the call to find_and_open_source
> and avoiding the split at that point.  However, this might result in
> checks occuring in multiple places - I haven't looked for this.
> 
> I'm not familiar with the gdb source so I'm not sure which solution will
> be more appropriate.  Putting the fix in find_and_open_source() would be
> more self contained, however this might affect other clients of
> find_and_open_source() in ways I haven't considered.

Well, I haven't had enough time to investigate this more, however, I did
find some odd results with the example I came up with. For example, if
I do 'info sources' before the dir command is applied, GDB spits out the
relative path. However, if I do the dir command, and then do 'info
sources', then GDB spits out the absolute path.

Once GDB has the absolute path, if I then do 'list uut.h:1', GDB can
still not find the file. If I do 'list ../include/uut.h:1',
then I get an Internal GDB error. Do you get these same results?

If so, find_and_open_source is finding the fullname, even though things
are still not working properly. Hopefully I'll have more time to look
into this today.

Thanks,
Bob Rossi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]