Re: gdb_realpath: dealing with ./ and ../

[Daniel Jacobowitz <drow@false.org>]

On Fri, Jan 04, 2008 at 11:38:44AM -0500, Aleksandar Ristovski wrote:
> BUT...
> This does not solve all my problems. In fact, when debugging on linux a
> binary cross-compiled on windows, it won't work:
> 
> IS_ABSOLUTE_PATH macro will differ depending on the configured gdb host. The
> problem with this is when one is debugging binary cross-compiled on windows,
> on a unix host, IS_ABSOLUTE_PATH will return 0 on "C:.." style paths which
> is not correct. Looking at the code, in many places we concatenate directory
> and file name if IS_ABSOLUTE_PATH returns zero so in case of cross-compiled
> binary I suspect there will be many issues.

Yes, this is something I've been meaning to fix for ages, but never
had time.  We need versions of IS_ABSOLUTE_PATH, FILENAME_CMP, and the
other related macros which handle DOS pathnames regardless of the host
system.  We should give them different names, though, so that both are
available (sometimes we need to manipulate host paths).

> > > 2. Problem two - one physical file is specified with two pathnames.
> > 
> > The specific case that's important here is associating the main file
> > from a dwarf2 CU DIE with the right lines from .debug_line.  When we
> > go to create that subfile we haven't created the other subfiles yet.
> > So what we need, I think, is to handle this in dwarf2read.c by walking
> > through the filename / directory table.
> 
> dwarf2read.c calls start_subfile or start_symtab which in turn calls
> start_subfile. I think we should let our readers deal with "compiled" paths
> (i.e. as found in the binary), without conversion. In start_subfile,
> however, we can do something with paths. Currently, we do not try to
> substitute-path on paths coming from the binary, even though they are
> clearly our source paths and should be dealt with the same as with any other
> source path. 

Substitute-path is designed to convert paths coming from the binary
into paths for the host system.  I don't understand why you're calling
it this early; it doesn't matter if these files exist on the host
system or not.

I always have trouble understanding changes to this part of GDB.
It would help a lot if you could write test cases.  We can use
gdb.dwarf2/ to construct arbitrary DWARF-2 contents, with relative or
absolute paths as needed.  If you have trouble writing the test cases,
I can do it if you send me a couple of example binaries, and the
before and after expected results.

Or you might ask Joel or Eli to look at your patches.

> Note2: for some reason, my post to gdb-patches didn't go through even after
> two attempts. There I submitted only source.c change dealing with rewriting
> source path in case when NAME is an absolute path and at the same time
> DIRNAME is not NULL (which can happen).

Please try using text for patches, instead of binary attachments.
ChangeLog entries would be nice, too.

-- 
Daniel Jacobowitz
CodeSourcery