[cdt-debug-dev] Attempt to open file w/absolute path

[Øyvind Harboe <oyvind.harboe@xxxxxxxxx>]

> >- There is no canonical representation. If a path originates
> >  from GDB, is used in Eclipse and fed back to GDB, then the
> >  path must *not* be converted to Eclipse speak and back to GDB
> >  speak, because any such transformation is inheritely lossy.
> >  Eclipse must store the original Eclipse/GDB path.
> >  E.g. today breakpoints are not persisted correctly between
> >  debug sessions due to such lossy conversion.
> 
> Not sure about this. Can you give examples?

Are you asking me to show an example of where the assumption that there
is a canonical path is wrong?

I don't have a full understanding of the details nor have I thought very
carefully about this. 

However, I believe that the burden of proof should be on those that make
the assumption that there is a canonical path representation. 

Here is something to ponder:

What does "break foo.c:123" mean?

GDB figures out which file this is referring to based upon the
information in the executable, launch parameters and its own
ideosyncrasies.

In my experience CDT records such breakpoints, but they are not restored
correctly the next time I launch GDB through CDT, presumably because
"break nonexistant.c:123" does nothing and CDT believes that it restored
the breakpoint. I haven't investigated due to the whole outstanding
source path issue.

Why is it necessary or a good idea to convert to a canoncial
representation?

Why not keep the original data around and then convert the original data
to whatever representation that is needed in any one context? 

Common enough approach. Take an integer that originates as a string or
"0x10" and "10". Store as a string within a class and introduce
toDecString(), toHexString(), toInt(), original() methods. 

Throw in a Java interface to make either GDB, plugins or CDT able to
originate such objects.

This should keep CDT & GDB happy regardless of their respective
particularities. 

-- 
Øyvind Harboe
http://www.zylin.com