[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Source locator fails for file paths starting with \\
|
I know the escaping of slashes has been worked on
before.
We should check the history of changes for MIParser and see
when this extra line was added.
But yes, please open a bug to track
this.
Thanks
Hi,
When stepping into printf, gdb reports the path of
printf.c as follows:
\\build\\tree\\RD-2011.2_kuma\\p4root\\Xtensa\\Target-libs\\newlib\\newlib\\libc\\stdio\\printf.c
This
string is unnecessarily escaped again by the MIParser in DSF, resulting
in:
\\\\build\\\\tree\\\\RD-2011.2_kuma\\\\p4root\\\\Xtensa\\\\Target-libs\\\\newlib\\\\newlib\\\\libc\\\\stdio\\\\printf.c
When
this string is converted into an IPath object, it is de-escaped into a path
like:
//build/tree/RD-2011.2_kuma/p4root/Xtensa/Target-libs/newlib/newlib/libc/stdio/printf.c
rather
than the correct path:
/build/tree/RD-2011.2_kuma/p4root/Xtensa/Target-libs/newlib/newlib/libc/stdio/printf.c
Due
to the extra forward slash in the beginning, source locator fails for
printf.c
This is due to a bug in the MIParser for DSF, where it
unnecessarily inserts extra escape chars into the strings returned by
gdb.
MIParser code for CDI:
private String translateCString(FSB
buffer)
...
if (c == '\\') {
if (escape)
{
sb.append(c);
escape = false;
} else {
escape = true;
}
}
MIParser code for
DSF:
private String
translateCString(FSB buffer)
...
if (c == '\\') {
if (escape)
{
sb.append(c);
sb.append(c); //this extra append causes the path to have extra slashes in the
beginning.
escape = false;
} else {
escape = true;
}
}
Should I file a bug and
attach a patch to remove the extra append() call?
Thanks
Abeer
Bagul
Tensilica India