search

eclipse-cdt / cdt

Eclipse CDT™ C/C++ Development Tools
http://eclipse.org/cdt
Eclipse Public License 2.0
299 stars 197 forks source link

BufferUnderflowException parsing DWARF v5 debug information #443

Closed jld01 closed 1 year ago

jld01 commented 1 year ago

A BufferUnderflowException is triggered when presenting source files relating to a PE64 executable file in the Project Explorer:

java.nio.BufferUnderflowException
    at java.base/java.nio.ByteBuffer.get(ByteBuffer.java:798)
    at java.base/java.nio.ByteBuffer.get(ByteBuffer.java:826)
    at org.eclipse.cdt.utils.debug.dwarf.Dwarf.readAttribute(Dwarf.java:822)
    at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parseDebugInfoEntry(Dwarf.java:606)
    at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parseDebugInfo(Dwarf.java:498)
    at org.eclipse.cdt.utils.debug.dwarf.Dwarf.parse(Dwarf.java:451)
    at org.eclipse.cdt.utils.debug.dwarf.DwarfReader.getSourceFilesFromDebugInfoSection(DwarfReader.java:663)
    at org.eclipse.cdt.utils.debug.dwarf.DwarfReader.getSourceFiles(DwarfReader.java:641)
    at org.eclipse.cdt.internal.core.model.Binary.addSourceFiles(Binary.java:315)
    at org.eclipse.cdt.internal.core.model.Binary.computeChildren(Binary.java:285)
    at org.eclipse.cdt.internal.core.model.Binary.buildStructure(Binary.java:271)
    at org.eclipse.cdt.internal.core.model.Openable.generateInfos(Openable.java:264)
    at org.eclipse.cdt.internal.core.model.CElement.openWhenClosed(CElement.java:428)

The executable contains DWARF v5 debug records generated by MinGW64 gcc:

$ gcc --version
gcc.exe (Rev6, Built by MSYS2 project) 13.1.0

The issue is caused by the presence of debug information using operand form DW_FORM_implicit_const which is not supported by the CDT DWARF parser.

jld01 commented 1 year ago

With MinGW projects, I've noticed that the contributing source file list in Project Explorer can contain many files relating to run-time libraries provided by the toolchain: image These files are typically not present on the local filesystem but might be present if the user has built their own toolchain locally. Attemping to open these files will result in an empty editor part. Does anyone see value in listing these files in Project Explorer or should we filter out files that do not exist? Of course, there would be a processing cost associated with testing for the existence of these files.

Cc: @jonahgraham @Torbjorn-Svensson

Torbjorn-Svensson commented 1 year ago

With MinGW projects, I've noticed that the contributing source file list in Project Explorer can contain many files relating to run-time libraries provided by the toolchain: image

Is your toolchain stripped? To me, it looks like these entries could be the result of running a toolchain that is not stripped and in that case, I would assume that it would be correct to list the files. If you decide to go down the verify-that-the-file-exist route, then I think that you would have to have something like the source file mapping, as the location for the resource on your system might not be the same as on the system that was used to build the binary, but perhaps this is needed anyway...?

jld01 commented 1 year ago

Thanks for your comments, @Torbjorn-Svensson. You wrote:

Is your toolchain stripped? To me, it looks like these entries could be the result of running a toolchain that is not stripped

Yes, I assume that the MSYS2 MinGW64 toolchain is released without stripping the run-time libraries.

and in that case, I would assume that it would be correct to list the files.

It might be formally correct, but it seems unhelpful to the majority of CDT users. For small CDT projects, the valid project source files can be difficult to identify among the set of library source files that are not present. Some source files (eg stdio.h) may appear to be duplicated if the run-time library was built using header files with the same name but a different file path.

If you decide to go down the verify-that-the-file-exist route, then I think that you would have to have something like the source file mapping, as the location for the resource on your system might not be the same as on the system that was used to build the binary, but perhaps this is needed anyway...?

I will push this patch as-is (no filtering) for now and we can see if there is any feedback from the user community. Users do have the option to strip the run-time libraries themselves.