Yes. QEMU/qemu-0.9.1/hw/omap.c
I have to note that QEMU is the project name, qemu-0.9.1 is the Linked
folder mapped to D:\Dvs\Project\qemu-0.9.1. I suppose this issue does not
depend on Linked Forder usage.

> - Is there another file omap.c in a different folder in the project?

No, there is no more files with this name.

> I can try to help solving your particular problem, but I think the cygwin
> issue with that warrants opening a bug in bugzilla. Can you do that?

I will.

I would like to mention that Debug Congurations seems to support this kind
of mapping through Source Lookup Path (manually configured). Perhaps this
could be expanded to Error Parsers?

Dmitry Smirnov wrote:
>>> /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/omap.c:118: undefined reference to
>>> `ffs'
>> Couple of questions:
>> - Is this path inside your project?
> Yes. QEMU/qemu-0.9.1/hw/omap.c
> I have to note that QEMU is the project name, qemu-0.9.1 is the Linked
> folder mapped to D:DvsProjectqemu-0.9.1. I suppose this issue does not
> depend on Linked Forder usage.
>> - Is there another file omap.c in a different folder in the project?
> No, there is no more files with this name.

Seems to work for me with linked folder on cygwin. Can you try most recent
CDT build? There were a couple bugs fixed recently related to that.

>> I can try to help solving your particular problem, but I think the cygwin
>> issue with that warrants opening a bug in bugzilla. Can you do that?
> I will.
Perhaps it is not necessary if the latest build works for you.

> I would like to mention that Debug Congurations seems to support this kind
> of mapping through Source Lookup Path (manually configured). Perhaps this
> could be expanded to Error Parsers?
How do you configure that?

>> I would like to mention that Debug Congurations seems to support this kind
>> of mapping through Source Lookup Path (manually configured). Perhaps this
>> could be expanded to Error Parsers?
> How do you configure that?
If you mean Debug Configuration, I never configured it, it wasn't needed
for my other projects. But I know that I can create Path Mapping and map
/cygdrive/d to D:\, for instance.

Is it possible that some cygwin (or system) configuration lead to this
issue?
How Eclipse maps such cygwin path to local file system? Does it use
cygpath utility?

I have a similar problem and no solution :-(.
I am using the MS Visual C++ compiler on Linux with Wine. So I can compile
for Linux (gcc) and Windows(msvc) on the same platform at the same time.
The compiler output (cl.exe) uses, of course, Windows style path but
Eclipse expects Linux paths. A path mapping from Wine to Linux would be
very helpful to be able to click errors/warning in the Problem View.

Axel

> Hi,

> I'm using Eclipse to debug QEMU simulator.
> When compiling this project, Cygwin produces error messages with path to
> file like

Hi there,
I tried to follow your steps in debugger and got slightly different
results.

Dmitry Smirnov wrote:
> When path is processed by GCCErrorParser, it finally goes to
> ErrorParserManager.findFilePath.
> This method fails to find the file in usual way and tries to use cygpath.
> This was successfull and cygpath returns
> D:DvsProjectqemu-0.9.1hwomap.c (at ErrorParserManager.java:334.
So far so good.

> Then at line 337 it is converted to hwomap.c (i.e. relative to project
> root) and file was found in workspace at line 341. Its path is
> /QEMU/hw/omap.c.
I am not getting to line 337. The condition on line 311
fBaseDirectory.isPrefixOf(fp) is false and I get to line 315 so the proper
marker is generated.
fBaseDirectory=E:/EclipseGanymedeSR1/runtime-EclipseApplicat ion/QEMU and
fp=/cygdrive/e/Dvs/Project/qemu-0.9.1/hw/omap.c (using drive E: for the
test). Nothing in common. What is your fBaseDirectory?

Andrew

> At line 353 the relative path hwomap.c (not the path of the file found in
> workspace) is converted to canonical path. The result of this conversion
> is D:EclipseGanymedeSR1hwomap.c !!

> D:EclipseGanymedeSR1 is the path where my Eclipse is installed.

> Thus, mapping to a file is failed and error message is attached to a
> project...

>> Then at line 337 it is converted to hwomap.c (i.e. relative to project
>> root) and file was found in workspace at line 341. Its path is
>> /QEMU/hw/omap.c.
> I am not getting to line 337. The condition on line 311
> fBaseDirectory.isPrefixOf(fp) is false and I get to line 315 so the proper
> marker is generated.
> fBaseDirectory=E:/EclipseGanymedeSR1/runtime-EclipseApplicat ion/QEMU and
> fp=/cygdrive/e/Dvs/Project/qemu-0.9.1/hw/omap.c (using drive E: for the
> test). Nothing in common. What is your fBaseDirectory?

D:/Dvs/Project/qemu-0.9.1
This value was applied in initErrorParserManager. Argument
('workingDirectory') have the same value.
Build location of the project was set up as
${workspace_loc:/QEMU/qemu-0.9.1}

Well, my project is a makefile project.
I do not know straightforward way to change directory from Eclipse
directly. At least, build command like
cd ${workspace_loc:/QEMU/qemu-0.9.1} && make
does not work.

So, I created gotodir.cmd in the ${workspace_loc:/QEMU} and use the
following command
gotodir.cmd ${workspace_loc:/QEMU/qemu-0.9.1}

> Well, my project is a makefile project.
> I do not know straightforward way to change directory from Eclipse
> directly. At least, build command like
> cd ${workspace_loc:/QEMU/qemu-0.9.1} && make
> does not work.
Try this:
make -C ${workspace_loc:/QEMU/qemu-0.9.1}

There is one more issue with paths. Perhaps it is not related directly to
the one reported in previous post.

So, I've got a makefile project for skyeye-1.2.5.
It is set up in the following way: project is created in the root of the
skyeye source tree (i.e. there is no linked folder to source code), build
location ${workspace_loc:/Skyeye_1.2.5}.

As you can see, log produces relative paths. Moreover, make is recursively
called in few directories (in this case it is
'/cygdrive/d/Dvs/Project/Skyeye_1.2.5/device'. So the path
'lcd/skyeye_lcd_win32.c' is relative to
'/cygdrive/d/Dvs/Project/Skyeye_1.2.5/device'.

Here is what happens in ErrorParserManager.
fBaseDirectory is set to D:/Dvs/Project/Skyeye_1.2.5.
findFilePath() is called with filePath='lcd/skyeye_lcd_win32.c'
Since it is not absolute, at line 318 'path' is asigned with
'/cygdrive/d/Dvs/Project/Skyeye_1.2.5/device/lcd/skyeye_lcd_ win32.c' which
is correct Cygwin path to the file.
findFileInWorkspace() cannot find this file (line 325) and execution goes
to cygpath check.
cygpath converts filePath (which is relative 'lcd/skyeye_lcd_win32.c') to
'lcd\skyeye_lcd_win32.c'
Since fBaseDirectory is not a prefix of this path, 'path' is assigned to
'lcd/skyeye_lcd_win32.c' at line 339.
findFileInWorkspace() at line 341 returns a file with path
'/Skyeye_1.2.5/lcd/skyeye_lcd_win32.c' which is imaginary and is not
correct ('device' directory is absent).

Later is it coverted to canonical
D:\EclipseGanymedeSR1\lcd\skyeye_lcd_win32.c which is also wrong and this
process fails...

Are you still using CDT 5.0.1? Can you try 6.0 build? I believe that the
issue with relative paths was fixed. It should scan all the files in your
project to find the file which rear matches (unless there are multiple
files like that).

> Here is what happens in ErrorParserManager.
> fBaseDirectory is set to D:/Dvs/Project/Skyeye_1.2.5.
> findFilePath() is called with filePath='lcd/skyeye_lcd_win32.c'
> Since it is not absolute, at line 318 'path' is asigned with
The file should be resolved long before that - in 6.0 version.

> I have a similar problem and no solution :-(.
> I am using the MS Visual C++ compiler on Linux with Wine. So I can compile
> for Linux (gcc) and Windows(msvc) on the same platform at the same time.
> The compiler output (cl.exe) uses, of course, Windows style path but
> Eclipse expects Linux paths. A path mapping from Wine to Linux would be
> very helpful to be able to click errors/warning in the Problem View.

Path mapping probably won't help you because Linux treats name like
"C:\src\Hello.cpp" as one continuous filename:

Can you add a comment to https://bugs.eclipse.org/bugs/show_bug.cgi?id=261913 ?
I think it could be resolved in the scope of this task, after all "cygpath
-w /usr/bin" converts it to proper Windows path. I'll try to find some
time to look at this one. We have similar issue with absolute /usr/* paths
although not related to cygwin.

> I'm using Eclipse to debug QEMU simulator.
> When compiling this project, Cygwin produces error messages with path to
> file like

> /cygdrive/d/Dvs/Project/qemu-0.9.1/hw/omap.c:118: undefined reference to
> `ffs'
> These message are shown at the Problems view but not operable: I cannot go
> to source by clicking at the problem.
> Most likely, Eclipse/CDT cannot map /cygdrive/d/ to D:
> Is there any way to tell Eclipse how to do this?

You know, it appears that there *is* another way. Try right-click on the
problem in Problems view, then "Open external location". I am not sure
about markers, they show up in the opened file in some cases but in others
do not.

> You know, it appears that there *is* another way. Try right-click on the
> problem in Problems view, then "Open external location". I am not sure
> about markers, they show up in the opened file in some cases but in others
> do not.

Great, this works. Even for /usr/include/math.h
The only point here is that files that are actually inside the project
(for instance, I have a compilation warning for common/exteption.c which
is actually located at path /Skyeye_1.2.5/arch/mips/common/exception.c)
are treated as external. At least they are marked with a "folder"
decoration of the icon (in the document title) and "Show In -> Project
Explorer" does not work.

Axel Mueller wrote:
> I have a similar problem and no solution :-(.
> I am using the MS Visual C++ compiler on Linux with Wine. So I can compile
> for Linux (gcc) and Windows(msvc) on the same platform at the same time.
> The compiler output (cl.exe) uses, of course, Windows style path but
> Eclipse expects Linux paths. A path mapping from Wine to Linux would be
> very helpful to be able to click errors/warning in the Problem View.

Can you provide some examples of output you are getting and what path
mapping you hope to get? Ideally in a form of bugzilla task. I am working
on more improvements in this area and would like to consider corner and
nut cases.