0

I am trying to debug my hypervisor using GDB server (via VMware). Unfortunately, GDB prints wrong values for non-pointer type variables.

For example, I have 2 variables declared as follows:

WORD fileType;
WORD_PTR pfileType = &fileType;
fileType = 5;

I have put a breakpoint right after the assignment to fileType (using the "native debug" VS Code plugin), and on GDB I ran the following:

print fileType
0

print *pfileType
5

So, I printed the addresses, and it is obvious that GDB is using the wrong address for the fileType variable:

print &fileType
(WORD *) 0x64013dc07d66

print pfileType
(WORD_PTR) 0x64013dc07e6e

I have tried to add the -fvar-tracking flag (according to this post), but I still get the exact same output. Here is the full list of flags that I am using to compile my code:

-nostdlib \
-c \
-fPIC \
-w \
-fno-stack-protector \
-mno-red-zone \
-nostdinc \
-g3 \
-ggdb \
-fshort-wchar \
-fvar-tracking \
-fno-omit-frame-pointer

Any ideas why this is happening? Perhaps I am doing something wrong?

Amir Shalom Yeshooroon
  • 21
  • 3
  • 2
    Perhaps something modified `pfileType` after initialization but before you inspect it with gdb? gdb has an option to set a hardware breakpoint that will catch unintentional modifications, which works much more reliably than any compiler-based technique. – Sam Varshavchik Jan 10 '21 at 16:05
  • 1
    Exactly when and where do you print the values of the variables in the debugger? At the exact line of the `pFileType` definition, or *after* the definition? And are both variables still in scope? Please [edit] your question to include a [mcve] and tell us exactly when and where the debugger is stopped when you check the values. – Some programmer dude Jan 10 '21 at 16:05
  • Thank you @Someprogrammerdude, I edited the post and included the missing information – Amir Shalom Yeshooroon Jan 10 '21 at 16:20
  • As Sam suggested, put a hardware breakpoint after `WORD fileType;` . TO add the hardware breakpoint use `watch -l fileType` – The Philomath Jan 10 '21 at 16:42
  • Your post is still missing the most important piece of information: what is the *minimal **reproducible** example* of the code, and where and *how* exactly did you stop when you ran those commands in GDB? "Right after the assignment to fileType" doesn't mean much. – Marco Bonelli Jan 10 '21 at 16:43
  • @MarcoBonelli I am using a VS Code plugin called "native debug" (in "GDB attach" mode). This code isn't "stand-alone" and in order to reproduce the issue, the whole system must be compiled and attached to an existing OS on VMware. – Amir Shalom Yeshooroon Jan 10 '21 at 16:57
  • I see, that makes it harder to reproduce the issue though. Are you able to create a minimal program with only a simple main and the above code which reproduces the issue? That would be great. If not, then the problem is somewhere else (either an issue in your debugging setup or an issue caused by other code that is not included in the post). – Marco Bonelli Jan 10 '21 at 17:01
  • You say that you "have put a breakpoint right **after** the assignment to fileType" (emphasis mine). So since you assign the value `5` to `fileType` then printing `*pfileType` should indeed print the value `5` (since that's the value of `fileType` where `pfileType` is pointing). If it's non-trivial to replicate or even give us more context, then it's going to be really hard for us to help you unfortunately. All we can really do is to guess wildly. – Some programmer dude Jan 10 '21 at 17:09
  • Other than that, have you tried other means of debugging? Like "printf" debugging? Stepping through the code statement by statement in the debugger? Using tools like [Valgrind](https://valgrind.org/) or similar? – Some programmer dude Jan 10 '21 at 17:10
  • @Someprogrammerdude Thank you for commenting. I understand that it is possible to reproduce the problem with the information that I have provided, but this code is a part of a very large project. It is not a simple executable file. I indeed tried "printf" debugging. When I print the variables I see the correct values (in this case, the correct value of `fileType` is 5). My main suspicion is that GDB is not detecting the value of RSP correctly, since there is a difference of 0x108 between the "real" address of fileType (held by pfileType) and the wrong value reported by GDB. – Amir Shalom Yeshooroon Jan 10 '21 at 17:29
  • (I meant impossible, of course...) – Amir Shalom Yeshooroon Jan 10 '21 at 21:52

0 Answers0