[llvm-bugs] [Bug 45114] New: PDB debug info CV_ALLREG_VFRAME issue in 32 bit output, probably alignment problem

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45114

            Bug ID: 45114
           Summary: PDB debug info CV_ALLREG_VFRAME issue in 32 bit
                    output, probably alignment problem
           Product: new-bugs
           Version: 10.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mirek.fidler at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

First of all I am sorry I could not conjure a simple testcase, but the problem
depends on compiler emitting CV_ALLREG_VFRAME local variable records into the
database and those are hard to reproduce with small code.

I have downloaded toolchain here

https://github.com/mstorsjo/llvm-mingw/releases

Our small opensource project maintains ide environment that has native .pdb
debugging support (using dbghelp.dll) so I have started experimenting with llvm
pdb output.

C:\upp\bin/clang\bin\i686-w64-mingw32-c++.exe -c  -mthreads -g2 -static  
-fexceptions -D_DEBUG -O0 -g -gcodeview -fno-limit-debug-info
-fno-omit-frame-pointer -x c++ "C:\u\PdbTests\main.cpp"  -o
"C:/out/PdbTests/main.o"

Soon I have found that address of some local variables is 4 bytes off. Further
investigation revealed that the problem was for local variable symbols with
PSYMBOL_INFO.Register == CV_ALLREG_VFRAME.

After some more digging, I believe the issue is related to this:

The start of function looks like

004018D0  push ebp 
004018D1  mov ebp,esp <----
004018D3  push esi 
004018D4  and esp,byte -0x8 <----
004018D7  sub esp,0xc80 

So there is an alignment of esp, but the value in epb is still unaligned.
However the values emmitted to .pdb in PSYMBOL_INFO.Address seem to be relative
to ALIGNED value, which sometimes leads to offset being invalid by 4. (All
further addresses in the code are esp based).

I have tried following workaround in our debugger:

.....
        if(pSym->Flags & IMAGEHLP_SYMBOL_INFO_REGRELATIVE) {
                if(pSym->Register == CV_ALLREG_VFRAME) {
                        if(c.pdb->win64)
                                v.address += c.pdb->GetCpuRegister(*c.context,
CV_AMD64_RBP);
                        else
                        {
                                adr_t ebp =
(adr_t)c.pdb->GetCpuRegister(*c.context, CV_REG_EBP);
                                if(c.pdb->clang)
                                        ebp &= ~(adr_t)7;  // Workaround for
supposed clang/win32 issue
                                v.address += ebp;
                        }
                }
                else
                        v.address += (adr_t)c.pdb->GetCpuRegister(*c.context,
pSym->Register);
        }
.....


and that seems to completely fix the issue, but I think this still counts like
a bug... also posting this here for future reference for other unfortunate
debugger developers...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200305/28c525c2/attachment.html>