Community
Participate
Working Groups
Build Identifier: 20100917-0705 Hi all, I'm running into a strange problem where eclipse cdt isn't recognizing a binary executable compiled with Borland/CodeGear. However, it has no trouble with executables created with these tools: msvc, digital mars compiler, mingw-gcc, executable created with the PE-Lib API. After some extensive analysis of the difference in the generated PE file structure, it appears the problem is coming from the e_lfanew data field in the Dos Header. PE executables that the binary parser recognized all had a e_lfanew value <= 0x100h. The compiled PE executable from Borland/CodeGear had a e_lfanew value of 0x200h, which the parser did not recognize as a valid executable. As an experiment, I hand-modified the Borland executable with CFF Explorer so that the e_lfanew has a value of 0x100h instead of 0x200h. After saving the modifications, a refresh in the Eclipse IDE properly recognizes it as a valid PE executable! By recognize, I mean when you look in the C/C++ Projects Panel, the executable file shows either a bug icon or the blue circle with a right arrowhead inside it. When it's not recognize, the generic 01010 icon is shown for the executable instead. Reproducible: Always Steps to Reproduce: 1. Compile any simple hello world program with Borland/CodeGear compiler toolset. Can use any version as it seems to happen with all of them. 2. Start a new project in Eclipse CDT and have the root folder point to the location of where the compiled program is located. 3. Make sure the project is set to use the PE Binary Parser and not the ELF parser. You will see that the icon in the C/C++ projects pane isn't shown correct for that executable file. As a side effect, when you try to debug it or run it by right clicking project name->Run As (or Debug As)->1 Local C/C++ Application it will give the error message: Launch failed. Binary not found.
Can I get some response on this bug report?
Hi, Looks like good investigation. Maybe you could try making a patch? http://wiki.eclipse.org/Getting_started_with_CDT_development I think the changes would be in the org.eclipse.cdt.core plugin, in the package org.eclipse.cdt.utils.coff or org.eclipse.cdt.utils.coff.parser And this bug probably belongs to Component : cdt-core :)
Created attachment 186700 [details] PE parser Borland patch Knowing nothing about PE and just looking at the code...I just increased the hint buffer size and it works. Do you know what the exact hint buffer size should be? I don't want to just put a bigger number and hope for the best ;)
Actually, I have no idea what the hint buffer size is suppose to signify or represent. After looking through the documentation and COFF specs, I am unable to find what the max allowable value is for e_lfanew. Since this is a long type, 32-bit value on a typical i386 machine, I would guess e_lfanew could possibly be as high as 4,294,967,295(0xFFFF) -- though unlikely in practice for obvious reasons. I don't know how qualified I am to submit a patch fix for this though. I program primarily in C/C++ and I don't know any Java really. Add to this the fact that I don't even know the eclipse CDT codebase at all and you're asking for an impossible task. I can however test if your patch corrects the bug or not. But I'll need a way to get a build of eclipse with the patch applied somehow.
Created attachment 223697 [details] Test binary Here's a test exe I compiled when I first look at this.
