rainers / cv2pdb Goto Github PK

It would be nice if it were possible to strip the DWARF debugging information from the executable while maintaining compatibility with the generated PDB.

Hi,
What about the PDB to DWARF conversion? This would be extremely useful if you want to debug PDB files in Eclipse CDT. See here: https://mingw-w64.org/doku.php/contribute#debug_infos

I converted a .dbg file for a 64 bit executable to .pdb. The .pdb is 32 bit (DBI-Stream Machine = 332).

I guess this is why AMD uProf does not load the .pdb file. Does cv2pdb always create 32 bit .pdb from a .dbg file? Can a .dbg file be 64 bit? Could you please add an option to force the creation of a 64 bit .pdb?

In the following conditions:

1. Visual Studio 2013 or previous version is installed.
2. mspdb.dll version cannot be loaded from %path%.
3. One of mspdb.dll is available in MSVC installation directory.
   release version of cv2pdb crashes when trying to load mspdb140 via Studio SDK API.
   The exception occurs in https://github.com/rainers/cv2pdb/blob/master/src/mspdb.cpp#L99

Problem is ISetupConfiguration cannot be instantiated, result code is REGDB_E_CLASSNOTREG, so query is NULL, and query->EnumInstances leads to access violation.

We only add S_GPROC entries if the dwarf entry for a function contains both pchi and pclo entries. If the function has multiple code ranges, we can emit the first range as we do now and emit the additional ranges as S_SEPCODE entries (see https://github.com/Microsoft/microsoft-pdb/blob/082c5290e5aff028ae84e43affa8be717aa7af73/include/cvinfo.h#L4148 for the structure layout, and https://msdl.microsoft.com/download/symbols/iphlpapi.pdb/73C3E5A77A9CF1A38763A6DC6E671DC31/iphlpapi.pdb for a pdb with such entries).

Works great with MSVC debugger so far. However there is one issue.
MSVC debugger shows unions as well, however with this the 7th field is missing.

struct value {
    HKEY hKey;
    LPCSTR lpSubKey;
    LPCSTR lpKeyName;
    DWORD dwFlags;
    DWORD dwType;
    DWORD dwSize;
    union
    {
      DWORD vDWORD;
      DWORD vQWORD;
      LPCSTR vSZ;
    };
};

const value values[] = { }; // fill with some values.

I'm running VS2017 on Windows 10.

Here the build using nmake bin fails.

The following console output is from within the "x64 Native Tools Command Prompt for VS 2017":

C:\temp\cv2pdb>nmake bin

Microsoft (R) Program Maintenance Utility, Version 14.16.27027.1
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

        if     exist "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\\Common7\IDE\VCExpress.exe" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\\Common7\IDE\VCExpress.exe" /Build Release src\cv2pdb.sln
        if not exist "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\\Common7\IDE\VCExpress.exe" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\\Common7\IDE\devenv.exe" /Build Release src\cv2pdb.sln
NMAKE : fatal error U1077: "if": Rückgabe-Code "0x1"
Stop.

Running devenv /Build Release src\cv2pdb.sln directly stops as well because the solution needs an upgrade.

Workaround:

• Run devenv src\cv2pdb.sln
• Accept all "Unidirectional Upgrades"
• Select cv2pdb in the Project Explorer
• Go to Project Properties
• Change "Windows SDK Version" to 10.xxxx using the dropdown arrow
• Accept
• Right click cv2pdb in the Project Explorer, select build

A highly convinient conversion would be, to also convert back - to convert pdb to dwarf.

Is this a possibility for this project?

These dlls are proprietary and parts of Visual Studio.

How do I do that? I am using the WinDbg that is included in WDK 7.1.0. When the program associated with the generated PDB crashes, I am not able to use the bt command (it states "Operation not supported in current debugging session).

Is it possible to compile this with VS 2013? If not, is there a known location where I could get a copy of VS 2010? I couldn't a download link for it anywhere.

We started to use cv2pdb in the project blueCFD-Core a few days ago and it works very well... with only one exception, hence this report.

The build option -gdwarf has been used with g++ with over 300 different binaries (108 DLL and 228 EXE) and cv2pdb worked without problems on all of them, except for one.

This one is an 829 MB DLL file which results in cv2pdb to give an error code of 127, after what it seems to have generated a partial PDB file of 2.9 MB. Download link on DropBox for the file cv2pdb.bug.libfiniteVolume.7z (94 MB), which provides the file libfiniteVolume.dll that triggers this issue, is as follows: https://www.dropbox.com/s/68xaxtmmahxkqs1/cv2pdb.bug.libfiniteVolume.7z?dl=0

Currently our workaround has been to simply ignore the error and strip the debug data from the DLL with strip --strip-unneeded, (edit) which results in a DLL file with only 23 MB.

We are using:

• MSys2 software stack with the MinGW64 installation (last updated on the 29th of September, 2017), which comes with GCC 7.2.0.
• cv2pdb which was downloaded from the AppVeyor link provided here, on the 6th of October 2017.

I haven't managed to get the time needed to build cv2pdb myself from source code, therefore I haven't tried debugging it.

The size of the debug information in a project of mine has grown to more than 650 MB. cv2pdb now crashes with a bad alloc.

Hi,

I'm developing a C application that needs to display a stacktrace to the user when the application crashes. I'm using MinGW and I don't want to use a MSVC toolchain to build my application. So I'm looking to integrate cv2pdb into my build process so I can generate a PDB file that will work with standard Win32 stacktracing calls. However, it seems cv2pdb needs VisualStudio to be installed for it to generate PDB files. Upon closer inspection of the source, I see it seems to only rely on "mspdbXYZ.dll" where XYZ are some version numbers. I don't want to install VisualStudio on my main development workstation so I installed it in a Windows 10 VM. I then located the mspdb dll (In my case it was mspdb140.dll) and dumped it my cv2pdb folder located on my host machine, not the VM. I then tried to generate a pdb file by running: "cv2pdb.exe test.exe" where test.exe is located in the same folder as cv2pdb, is a valid PE image compiled with MinGW-w64, and contains DWARF4 debugging information via the GCC flags: "-gdwarf -dwarf-4 -g3". Some of the mspdb140 dlls work, and others do not. There are a total of 6 of them in my Windows 10 VM Visual Studio 2022 install directory, some were duplicates, some weren't but only a couple are recognized by cv2pdb. Of the ones that are recognized by cv2pdb, It simply fails with "cannot create PDB file". How can I fix this error? What does cv2pdb need from Visual Studio for it to generate a pdb file? I want to use cv2pdb without VisualStudio by copying the required dependencies. I should note that on the Windows 10 VM, most confusingly it works some of the time, but not when i place the DLLs directly into a cv2pdb folder on the machine. On my host machine, it never works. It either fails with a pdb generation error or a dll helper dll error.

Hi! I'm trying to use your app to get debugging symbols for the GPGME C library, so I can debug some issues with my usage of it from C#.

I've compiled my own version of libgpgme-11.dll with debug symbols intact, and have used cv2pdb to generate a PDB. Visual Studio says:

Loaded 'C:\Program Files (x86)\GnuPG\bin\libgpgme-11.dll'. Symbols loaded.

Which makes me think that it has found the PDB file.

However, It still says:

Source Not Available
Source information is missing from the debug information for this module

when I try to debug the library:

Do you know what could be causing it?

I've attached the original DLL, DLL output by cv2pdb, and the PDB file here: libgpgme-11.zip

There is 32-bit binary provided here: https://github.com/rainers/cv2pdb/releases/tag/v0.38
Shouldn't there be a 64-bit version as well?
Or is that possible to use 32-bit one to work with 64-bit exe/dll?

On Windows 10 when trying to convert this executable:
https://drive.google.com/open?id=1rLnF0UIa1ympra9U7zCQWmQpH0PaxpBD

cv2pdb crashes. We're using latest tool from the Release section.

test.cpp

int x = 4;
int y = 5;
int z = 6;

int main() 
{
    int a = 1;
    int b = 2;
    int c = 3;
    int *m = 0;
    *m = 1;
    return c;
}

g++ -O0 -g test.cpp -o test.exe
cv2pdb -C -ptest.pdb test.exe
devenv.exe /Run test.exe

Compiler: http://www.mirrorservice.org/sites/downloads.sourceforge.net/m/mi/mingwbuilds/host-windows/releases/4.6.3/32-bit/threads-posix/sjlj/x32-4.6.3-release-posix-sjlj-rev2.7z

Using cv2pdb from git b5dcff3, the local/global variables are not displayed and adding them to the watch window manually shows identifier is undefined. This was previously working in cv2pdb 0.31.

When the first state machine state in dwarf is a "reuse previous address" (adr == 0 in code), state.address become the value of state.last_addr which is not initialized to 0 and then corrupt every following reading (in my case Oxcccccccc). See code in dwarflines.cpp line ~247
To fix this I initialized last_addr to 0 which should be the default value if no address hasn't been set before in dwarf

why the folder https://github.com/rainers/cv2pdb/releases is empty? I do not have time to do the assembly

If I have a stripped executable with its DWARF debugging symbols as a separate file (stripped via objcopy), would it be possible to convert those into PDB symbols instead? Thanks!

I've been unable to debug my mscoff-built project, so I did some experimentation with a dummy project to see what was failing here.

I just tried all 6 permutations of [ldc2/dmd -m32mscoff] and [-g/-gc/no debug info], and also one control run without -m32mscoff.

Comparing the binary output between the builds, both compilers are definitely producing extra output when debug info is enabled (I figured one possibility was that the compilers simply didn't support embedding debug info into 32-bit mscoff but it seems that they do), but cv2pdb always reports no debug info found.

E:\code\dlang\temp\mscoff_tests>cv2pdb.exe coff_test-debugInfoC.exe coff_test-debugInfoC.pdb.exe coff_test-debugInfoC.exe: no codeview debug entries found

Is mscoff unsupported? : 0

I've generated a pdb from an exe with debugging info and try to debug it with windbg, but no locals are shown. Running cvdump on this pdb shows a lot errors, examples are:
Error on OpenTpi: 'Invalid file format' (11)
list[31] = LF_MEMBER, none, type = 0x116E, offset = Invalid Numeric Leaf
Size = Invalid Numeric Leaf, class name = TCGContext, UDT(0x0000137d)
qemu-system-i386_orig.zip

Note: I had updated the runtime's build process to set -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer in CFLAGS and CXXFLAGS, by default they used -ggdb.

Specifically, this is happening with cygwin/msys DLLs. The Git for Windows project has been trying to supply a PDB for the msys runtime (see git-for-windows/git/issues/356).

The x64 runtime DLL, msys-2.0.dll, is built with an image base address of 0x180040000 (Cygwin x64 default, AFAIK). That's too big for an int, but I see a lot of the cv2pdb types used to do math with offsets and the image base address are ints or unsigned ints. I suspect there are several places where this math overflows or underflows because of the large base address. There's also the call in main.cpp of exe.relocateDebugLineInfo(0x400000) where the windows default base address is hardcoded.

Attached is a .zip with enough unmodified and modified DLLs for reproduction or inspection. Contents are:

• msys-2.0.dll Original DLL, image base address 0x180040000
• msys-2.0d.dll Debug info stripped with objdump/objcopy
• msys-2.0d.dbg Debug info corresponding to msys-2.0d.dll
• msys-2.0-pdb.dll Debug info stripped with cv2pdb (DLL invalid/truncated)
• msys-2.0-pdb.pdb Debug info corresponding to msys-2.0-pdb.dll

I'm not sure how many types in cv2pdb would need to change to handle this, but from looking in to it some it seems like maybe a lot. It might also be necessary to add an optional command-line option to specify the base address if it can't be looked up before it's required in main.cpp.

Hello.

I am developing an app which is currently built with MinGW-W64 5.3.0 on Windows. As it always goes, a need arose to see stacktrace when on crash on consumer machine. Quick Google search led me to "Printing a Stack Trace with MinGW" article. I mindlessly copied code to see if it even works (article is almost 5 years now). Indeed it does and it is quite satisfactorily for my needs.

And so I started tinkering with it. Compiling without optimizations produces satisfactory trace for my needs.

PS F:\Projects\C++\mingw_stacktrace> g++.exe -std=c++11 -g main.cpp -lDbgHelp -o main.exe; ./cv2pdb.exe main.exe; ./main.exe
[0] function_c
[1] function_b
[2] function_a
[3] main
[4] public_all
[5] BaseThreadInitThunk
[6] RtlGetAppContainerNamedObjectPath
[7] RtlGetAppContainerNamedObjectPath

However, the moment I turn on regular optimization level (-O2) all info is lost.

PS F:\Projects\C++\mingw_stacktrace> g++.exe -std=c++11 -O2 -g main.cpp -lDbgHelp -o main.exe; ./cv2pdb.exe main.exe; ./main.exe
[0] public_all
[1] BaseThreadInitThunk
[2] RtlGetAppContainerNamedObjectPath
[3] RtlGetAppContainerNamedObjectPath

After that I decided to see if anything changes if I switch to MinGW-W64 8.1.0. Yes, some things have changed: stack trace without optimizations looks about the same, and with optimizations turned on it is a little bit better:

PS F:\Projects\C++\mingw_stacktrace> g++.exe -std=c++11 -O2 -g main.cpp -lDbgHelp -o main.exe; ./cv2pdb.exe main.exe; ./main.exe
[0] stack_trace
[1] main
[2] public_all
[3] public_all
[4] BaseThreadInitThunk
[5] RtlUserThreadStart

As of this moment, I cannot migrate to a newer version of MinGW-W64 (or to another compiler altogether).

Is it possible to get any kind of info with MinGW-W64 5.3.0? Upgrade to a newer version is planned, but it is a quite a long way away from now on still.

Hello.
I'm using cv2pdb to generate pdb files for c++ programs compiled with gcc 4.9.
When using boost libraries in my program I get symbols names which are so long that they exceed the 4096 bytes of the kMaxNameLen constant defined in symutil.h.
Changing the constant to a bigger size (8192 for instance) allows cv2pdb to output the pdb file but I'm not sure of the consequences of such a modification.
Is the 4096 bytes a limit of pdb files or can it be changed freely ?

hello,
I am using this nice program to debug mingw program and depending on commits of my project I got the error
assert(id.tag == idspec.tag);

cv2pdb.exe!_NMSG_WRITE(int rterrnum) Ligne 226 C
cv2pdb.exe!abort() Ligne 62 C
cv2pdb.exe!_wassert(const wchar_t * expr, const wchar_t * filename, unsigned int lineno) Ligne 156 C
cv2pdb.exe!CV2PDB::createTypes() Ligne 695 C++
cv2pdb.exe!CV2PDB::createDWARFModules() Ligne 880 C++
cv2pdb.exe!wmain(int argc, wchar_t * * argv) Ligne 183 C++

raised or not

when it's raised my program crashes at startup says :
exception at 0x00401010 in fcfspdb.exe : 0xC0000005 : access violated when writing at adress 0x00401010.

fcfspdb.exe!pre_c_init() Ligne 127 C++
[External code]
fcfspdb.exe!__tmainCRTStartup() Ligne 263 C++
[External code]

what does this assert stand for I am new to this kind of debugging and any help is appreciated,

I am using i686-w64-mingw under cygwin64 on windows 7

regards,
Pierre

cv2pdb writes the absolute path to the .pdb file in the "debug/CodeView" section. If I copy the executable to a target computer, Process Explorer cannot find the .pdb file.

Could you please use the relative file name or the file name provided on the command line?

BTW, the fix for #40 works in Process Explorer and Very Sleepy, but not in AMD uProf. Something is probably still missing.

Hi,

This project is great, but once your build system is on linux, then this would break the pipeline and would require windows machine just for generating the pdbs for mingw artifacts.

Did anyone attempt to port this to run on Linux before?
What are the challenges in doing so?

I think that mingw can be used for getting the windows headers.

Please share your thoughts and experiences

I see this error:

cannot add symbols to module, probably msobj140.dll missing

Where do I find this DLL? I have Visual Studio 2017 installed, however in C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE all I see is msobj120.dll and mspdb140.dll.

I get a crash running "cv2pdb -C DebugTest.exe" with latest git master.
Download: https://www.dropbox.com/s/xxj1m9j9hg54ceo/DebugTest.exe

It works if I use cv2pdb 0.31.

When trying to parse RSDS signature files, program reports "no codeview debug entries found". It's because only NB09/NB11 signatures supported. Function PEImage::initCVPtr() should return false and try DWARF segments if signature not supported:
if (memcmp(sig->Signature, "NB09", 4) != 0 && memcmp(sig->Signature, "NB11", 4) != 0)
{
// return setError("can only handle debug info of type NB09 and NB11");
dirHeader = 0;
dirEntry = 0;
return false;
}

I tried to split debug symbols from xul.dll which is compiled with gcc 8.1, and xul.dll file size is 2,882,488,917 bytes and cv2pdb returns "Can't get size". I think it may be cause by fstat can't handle this big size.

I'm debugging qemu (the binary is attached to "Invalid entrys in generated pdb" issue) and windbg does not show any locals. For example when debugging bdrv_co_rw_vmstate function, gdb shows as locals "drv" and "ret", and as arguments "bs", "qiov", "pos", "is_read".

I get this:

 {"message":"Build job with specified name not found or access denied."}

Could be a permission issue?

maybe you can restart the last commit build....

I'm not entirely sure how, but I've ended up with the situation where I have vswhere.exe, but no actual Visual Studio install (Just MSBuild/build tools, i think?)

Obviously I'm in the wrong for not having a working VS install, but I don't think the tool should hang either :)

As best as I can tell, it's hanging on the ReadFile at:

due to read being a pipe, and vswhere producing no output?

Procmon shows that's what it did last before hanging forever, at any rate (it was still running when this screenshot was taken):

I am using cv2pdb to convert DLLs generated with MinGW-w64 from DWARF to PDB. I recently started using OpenMP in that project. This causes cv2pdb to crash because now addUdtSymbol is being called with a null name from CV2PDB::createTypes, more specifically in these lines:

case DW_TAG_typedef:
    cvtype = appendModifierType(getTypeByDWARFPtr(cu, id.type), 0);
    addUdtSymbol(cvtype, id.name);

For now I just added if(!name) return false; to the beginning of CV2PDB::addUdtSymbol.

Minimal example:

Add the following to a new file, e.g., cv2pdb_crash.cpp:

__declspec(dllexport) void foo(int I)
{
    #pragma omp parallel for
    for(int i = 0; i < I; i++)
        continue;
}

Build a DLL:
g++ -fopenmp -O0 -g -shared cv2pdb_crash.cpp -o cv2pdb_crash.dll

Run cv2pdb:
cv2pdb -C cv2pdb_crash.dll

Observe crash.

It seems that LineInfoData struct in PEImage.cpp:565 should be split into two and second part of it can have multiple entries.

struct LineInfoData // size =12
{
    int funcoff;
    int funcidx;
    int funcsiz;
};
struct LineInfoData2
{
    int srcfileoff;
    int npairs;
    int size;
};

hex dump below is .debug$S section of my object file. (* - nparis, # - size)

  00000B20:                                  |F2  00  00  00  E8  00  00  00| E8 = 0C + 5C + 14 + 24 + 14 + 34
             --------------------------------+-------------++---------------+
  00000B30:  00  00  00  00  00  00  00  00  63  04  00  00||40  05  00  00 | 1st, *0A entries, size #5C
             -------------------------------+--------------++---------------+
  00000B40: *0A  00  00  00 #5C  00  00  00 :00  00  00  00  2F  01  00  80 |
             -------------------------------+                               |
  00000B50:  3A  00  00  00  2F  01  00  80  5D  00  00  00  2F  01  00  80 |
                                                                            |
  00000B60:  6B  00  00  00  2F  01  00  80  83  00  00  00  2F  01  00  80 |
                                                                            |  
  00000B70:  8A  00  00  00  2F  01  00  80  91  00  00  00  2F  01  00  80 |
                                                                            |  
  00000B80:  94  00  00  00  2F  01  00  80  9B  00  00  00  2F  01  00  80 |
                                           ++-------------------------------+
  00000B90:  9D  00  00  00  2F  01  00  80||C0  24  00  00 *01  00  00  00 | 2nd, *01 entry, size #14
             ---------------+--------------++--------------++---------------+
  00000BA0: #14  00  00  00 :D1  00  00  00  9C  02  00  80||40  05  00  00 | 3rd, *03 entries, size #24
             ---------------+---------------+--------------++---------------+
  00000BB0: *03  00  00  00 #24  00  00  00 :D8  00  00  00  2F  01  00  80 |
             -------------------------------+                               |
  00000BC0:  B4  01  00  00  2F  01  00  80  DE  01  00  00  2F  01  00  80 |
           ++-----------------------------------+---------------------------+
  00000BD0:||C0  24  00  00 *01  00  00  00 #14  00  00  00 :E8  01  00  00 | 4th, *01 entry, size #14
           ++--------------++-------------------------------+---------------+
  00000BE0:  05  03  00  80||40  05  00  00 *05  00  00  00 #34  00  00  00 : 5th, *05 entry, size #34 
             --------------++-----------------------------------------------+
  00000BF0:  0C  02  00  00  30  01  00  80  18  02  00  00  2F  01  00  80 |
                                                                            |  
  00000C00:  26  02  00  00  30  01  00  80  E1  03  00  00  3E  01  00  80 |
                                           ++-------------------------------+
  00000C10:  E7  03  00  00  44  01  00  80||                                
             ------------------------------++

Any advise on usage on MINGW32 produced exe?
Used in follow way: cv2pdb Orig.exe New.exe New.pdb

Getting error: cannot add line number info to module
New.pdb is created - cannot validate if correct
New.exe - is not present

Hi,

For the projects built in Delphi , there's a map2dbg utility that allows for converting the MAP files into DBGs in regular NB09 format.
Unfortunately, cv2pdb doesn't look for the external DBG file in case of IMAGE_FILE_DEBUG_STRIPPED flag set in PE header.
Is it possible to add such feature?
I can try to implement it if you agree to add this functionality.

Thank for the consideration!

Since the debug section is marked as IMAGE_SCN_CNT_INITIALIZED_DATA, OptionalHeader.SizeOfInitializedData should be adjusted accordingly when this section is added.
If a debug section was already present in the file, its flags should probably be checked to make sure SizeOfInitializedData is set to a correct value.

I'm not sure if this is a real problem. The EXEs and DLLs with unadjusted SizeOfInitializedData work just fine.
It's just a matter of consistency.

There are some fixes after last release. Do you plan to release new version?
Using official release is better than building it by myself and storing some where.

Hello folks,
Would you accept a small one-file contribution which let us build cv2pdb binary from command line with latest installed version of Visual Studio ?

If yes, then build process would look like:
native bitness: python -m minibuild
win32: python -m minibuild --model win32
win64: python -m minibuild --model win64

On my machine with VS-2017 installed target binaries are here:

• bin\output\exe\msvs2017-win32\release\cv2pdb.exe
• bin\output\exe\msvs2017-win64\release\cv2pdb.exe

minibuild itself is a pure python package,
so as a prerequisite for build Python-2.7 or Python-3.x is required.
And then minibuild package is supposed to be installed by pip: python -m pip install minibuild

If no, then just close this issue.

Using cv2pdb.exe my.exe (x64) results in a crash (Latest commit f75b963). Dr.Memory reports:

Error #4: UNADDRESSABLE ACCESS: reading 0x7b923044-0x7b923045 1 byte(s)
# 0 cv2pdb.exe!?                     +0x0      (0x013744d7 <cv2pdb.exe+0x144d7>)
# 1 cv2pdb.exe!?                     +0x0      (0x01370141 <cv2pdb.exe+0x10141>)
# 2 cv2pdb.exe!?                     +0x0      (0x013705ba <cv2pdb.exe+0x105ba>)
# 3 cv2pdb.exe!?                     +0x0      (0x01372842 <cv2pdb.exe+0x12842>)
# 4 cv2pdb.exe!?                     +0x0      (0x01378c59 <cv2pdb.exe+0x18c59>)
# 5 KERNEL32.dll!BaseThreadInitThunk +0x11     (0x769a336a <KERNEL32.dll+0x1336a>)
Note: @0:00:08.360 in thread 2856
Note: instruction: mov    (%eax) -> %dl

Hi, I just notice that MS has removed the autoexp.dat file in vs2019 and replaced with Natvis:
https://docs.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2019
such that INSTALL step4 cannot be done.
So is there any plan to update the INSTALL document or workaround?
tank you

struct Game
{
	unsigned short a[3];
};
struct Game game;

int main()
{
	return game.a[0];
}

This simple program compiled with mingw can be debugged in VS thx to cv2pdb.
But if the data is moved to a dll (__declspec(dllimport) struct Game game;) VS does not recognize any game variable anymore inside main.

The main difference in main.o DWARF debug info seems to be

DW_TAG_variable
  DW_AT_name	("game")
  DW_AT_type	(0x0000009a "Game")
  DW_AT_external	(true)
- DW_AT_location	(DW_OP_addr 0x0)
+ DW_AT_declaration	(true)

How to debug a program compiled with gcc?

I try to build .dll by gcc with -gdwarf option and use cv2pdb with -C option:
Visual Studio load pdb symbols but cant go into functions from .dll by F11

Hi,

I'm using MinGW64 and I was wishing to generate pdb files for the executables I've compiled so that I could print out debug information such as stack traces using the windows API. I compiled this current master branch using Windows 7 Visual Studio 2013 in debug x64 mode. Compilation runs fine with a few warnings.

But when I try to run cv2pdb on my executables I get the following error:

D:\Projects\mpc>cv2pdb test.exe
Assertion failed: abbrev, file d:\sources\cv2pdb-master\src\readdwarf.cpp, line
394

D:\Projects\mpc>

I've tried the same process on various other executables and I get the same result. Here is a sample executable you can try it on compiled from my ptest library.

Do you have any insight into this error? I'm happy to try and investigate and potentially contribute a fix but I'm really not sure where to start. I suspected it may be something to do with using MinGW64 rather than standard 32-bit MinGW but I'm not sure.

Thanks,

Dan

I'm experiencing a crash in CV2PDB::appendClassTypeEnum when it attempts to memmove() a negative number of bytes.

This is an EXE file which triggers the crash for me: https://openload.co/f/K76jjq2NBl8/entrypoint.zip
Generated by DMD 2.071.1 with -g on 32-bit Windows.

This is the state of the relevant variables at that point (as far as I could determine):

fieldlist =     004CAB72
type =          00002B30
name =          "__StructType"
len =           00000018
fieldlen =      0000CDCF
globalTypes =   004C9720
off =           00001452
copyoff =       0000E221
cbGlobalTypes = 00001452

memmove(dst = 0x004D7959, src = 0x004D7941, length = 0xFFFF3231);

Looks to me like fieldlen (equal to fieldlist->generic.len + 2) is much higher than it should be.

I'm not sure what other information would be helpful in diagnosing this bug, but please let me know how I can help. I'll do anything to get this fixed, I just wish I had the skills to understand what's going on here.