Cannot locate/associate source paths of certain lengths

[skeeto]

I've been experimenting with compiling using Mingw-w64 GCC then converting DWARF to PDB using cv2pdb (plus my patch to build with newer Visual Studio) so that I can debug using RemedyBG. To my amazement it actually works with both RemedyBG and Visual Studio. Except that it only works in RemedyBG if the source path is a certain length, something like length%4 == 3. I initially suspected cv2pdb was at fault, except that so far it's always worked in Visual Studio regardless of the source path length.

I can reproduce it using the simplest possible program:

int main(void) { return 0; }

Put this in C:\example\main.c, build with Mingw-w64 (in case it helps with reproduction, I'm using my toolchain configuration here), generate a PDB, then run in RemedyBG:

gcc -g -o example.exe main.c
cv2pdb example.exe
remedybg example.exe

When I hit F10 it goes straight into the disassembly window, and even if I manually open the source it doesn't associate it with debugging. With Visual Studio it works just as I expect:

devenv example.exe

The source path is C:\example\main.c, which is 17 characters long. Rename main.c to mainxx.c to make that 19 (19%4 == 3) or even mainxxxxxx.c (23%4 == 3):

move main.c mainxx.c
gcc -g -o example.exe mainxx.c
cv2pdb example.exe
remedybg example.exe

Now when I hit F10 in RemedyBG it takes me to the source file as I expect.

I spent quite awhile trying to figure out why certain programs worked while others didn't. Eventually I noticed the program itself didn't matter, but rather where I built it, ultimately narrowing it down to source path length. I still suspect cv2pdb may actually be at fault and that Visual Studio is just more flexible about locating the source in the face of a bogus PDB path.

[x13pixels]

That's quite a find! I'll see what's going on in RemedyBG and get this fixed up. Thanks!

[McKay42]

Similar setup here, please get this fixed soon (or maybe it actually is a cv2pdb bug?).

(Apparently I was very lucky to always randomly have compatible path lengths until cleanup today, so thanks @skeeto for the workaround, would have never guessed that myself, cheers.)

[x13pixels]

[0.3.8.0] Fixed handling of C13 line info subsection whose size was not 4 bytes aligned. In the two cases presented, the C13 subsections look like:

GCC/cv2pdb (main.c)

1. type: DEBUG_S_LINES (242); size: 56
2. type: DEBUG_S_LINES (242); size: 144
3. type: DEBUG_S_STRINGTABLE (243); size: 58 <- does not divide 4
4. type: DEBUG_S_FILECHKSMS (244); size: 16 [after fix to alignment]

GCC/cv2pdb (mainxx.c)

1. type: DEBUG_S_LINES (242); size: 56
2. type: DEBUG_S_LINES (242); size: 144
3. type: DEBUG_S_STRINGTABLE (243); size: 60 <- divides 4
4. type: DEBUG_S_FILECHKSMS (244); size: 16

Thanks @skeeto

[skeeto]

Awesome and thanks, George! I look forward to using RemedyBG in more situations.