Path translation in Zylin Embedded CDT plugin

[Øyvind Harboe]

I've made a new snapshot of the Zylin Embedded CDT (works w/unmodified
CDT CVS HEAD, though lacks GDB console improvements).

Here I've got three launch types:

- CygWin hosted GDB
- MinGW hosted GDB
- Eclipse == GDB host OS (typically Linux).

The different launch types handle translation back and forth between
CDT's pseudo-canonical file path syntax(e.g. path to breakpoints, source
code lookup, etc.) and file paths to GDB's file path syntax.

http://mail.zylin.com/pipermail/zylin-discuss_zylin.com/2006-March/000225.html

Comments?

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

[Mikhail Khodjaiants]

Øyvind,

Why do you need two different launch types for MinGW and CygWin? Is there
something that can not be covered by modified command factory?

Thanks,
Mikhail Khodjaiants
----- Original Message -----
From: "Øyvind Harboe" <oyvind.harboe-***@public.gmane.org>
To: <cdt-debug-dev-j9T/***@public.gmane.org>
Sent: Tuesday, March 14, 2006 6:44 AM
Subject: [cdt-debug-dev] Path translation in Zylin Embedded CDT plugin


I've made a new snapshot of the Zylin Embedded CDT (works w/unmodified
CDT CVS HEAD, though lacks GDB console improvements).

Here I've got three launch types:

- CygWin hosted GDB
- MinGW hosted GDB
- Eclipse == GDB host OS (typically Linux).

The different launch types handle translation back and forth between
CDT's pseudo-canonical file path syntax(e.g. path to breakpoints, source
code lookup, etc.) and file paths to GDB's file path syntax.

http://mail.zylin.com/pipermail/zylin-discuss_zylin.com/2006-March/00022
5.html

Comments?

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

[Øyvind Harboe]

> yvind,
>
> Why do you need two different launch types for MinGW and CygWin? Is there
> something that can not be covered by modified command factory?

The path translation is handled by sourceLocator & sourcePathComputer,
which both differ between CygWin & MinGW.

Maybe there is a different way to handle this, but fundamentally CygWin
and MinGW path translation differ so the split needs to happen
somewhere.

<launchConfigurationType
delegate="com.zylin.embeddedcdt.launch.cygwin.CygWinLaunch"
public="true"
name="Embedded debug launch(CygWin hosted GDB)"
modes="debug"
id="com.zylin.embeddedcdt.idle"
sourceLocatorId="com.zylin.embeddedcdt.sourceLocatorCygWin"
sourcePathComputerId="com.zylin.embeddedcdt.sourcePathComputerCygWin"
/>


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

[Øyvind Harboe]

> I can not promise I'll do this all for 3.1 (being busy working on some
> internal issues) but I'll try.

Thanks!

> BTW, what do you mean by "Recover some lost GDB output"? Is this related to
> those mi commands that are not compatible with CLI.

It has been so long since I did this that I honestly don't recall.
However, e.g. "load" produces some output that is swallowed by CDT by
default.

Embedded applications can also print to something akin to stdout/stderr
which is routed in hardware via the GDB server protocol, which CDT puts
into the bitbucket.


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

[Mikhail Khodjaiants]

> Embedded applications can also print to something akin to stdout/stderr
> which is routed in hardware via the GDB server protocol, which CDT puts
> into the bitbucket.
Is this is similar to the "monitor" problem
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=119370)?

BTW, there have been informal discussions to implement a special
gdb-oriented launch type that will cover local and remote debugging. This
will allow us to get rid of all other gdb launch configuration types. I have
looked at the James P. Lynch's tutorial, but I 'll need more information.

----- Original Message -----
From: "Øyvind Harboe" <oyvind.harboe-***@public.gmane.org>
To: <cdt-debug-dev-j9T/***@public.gmane.org>
Sent: Tuesday, March 14, 2006 12:59 PM
Subject: [cdt-debug-dev] Residual CDT hacks


> I can not promise I'll do this all for 3.1 (being busy working on some

> internal issues) but I'll try.

Thanks!

> BTW, what do you mean by "Recover some lost GDB output"? Is this
related to
> those mi commands that are not compatible with CLI.

It has been so long since I did this that I honestly don't recall.
However, e.g. "load" produces some output that is swallowed by CDT by
default.

Embedded applications can also print to something akin to stdout/stderr
which is routed in hardware via the GDB server protocol, which CDT puts
into the bitbucket.


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