Re: [RFC] new substitute path when loading feature

Vladimir Prus
2008-05-17T16:22:36Z

Vladimir Prus wrote:

> Daniel Jacobowitz wrote:
>
>> On Tue, May 13, 2008 at 03:20:41PM -0400, Daniel Jacobowitz wrote:
>>> On Tue, May 13, 2008 at 03:11:22PM -0400, Aleksandar Ristovski wrote:
>>> > No, this particular issue is not because of the slashes, but rather
>>> > due to IS_ABSOLUTE_PATH returning false on a path like "c:/Temp...".
>>>
>>> OK. I think I "fixed" FILENAME_CMP and not IS_ABSOLUTE_PATH, but it
>>> would not be hard to do both.
>>>
>>> I'll try to post something tonight.
>>
>> Sorry, my existing patch was a mess so I had to rewrite it. I haven't
>> really tested this; it doesn't break a native Linux GDB in any case
>> that I consider significant. See the comments in defs.h and utils.c
>> for the details.
>
> I probably miss somethings, but it looks like the uses of IS_ABSOLUTE_PATH
> in symtab.c:lookup_symtab and symtab.c:lookup_partial_symtab should be changed to
> GDB_IS_ABSOLUTE_PATH, too?
>
> Also, I see IS_ABSOLUTE_PATH been used in source.c:openp, inside the
> "if (filename_opened)" block at the end, and your patch does not seem to change
> that.

Ok, the last one probably need not be changed, since we appear to always
have host patch at this point. OTOH, I'm still unsure about symtab.c --
is calling lookup_symtab with the absolute path on the system where binary is
compiled (not where gdb is run) something we want to support? In general, it seems
that having IS_ABSOLUTE_PATH and GDB_IS_ABSOLUTE_PATH, and needing to use some reasoning
where to use which one is too risky -- should we use GDB_IS_ABSOLUTE_PATH everywhere?

- Volodya