-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support dllimport data #59
Comments
I don't see this working when compiling dll and exe with the Microsoft compiler, so it's probably not so easy to implement. You would have to make the entry in the import table a reference to a Game instance and rename it "game" somehow... |
Seems like my edit got lost. When compiling with msvc the pdb contains
Maybe they also do something special based on the naming convention ( |
Indeed, the symbol is there, but it needs to be extern "C" to actually be able to evaluate it in the watch window because it needs to be spelled out as is ( Maybe the DWARF output makes more sense, though. |
I did compile it as C. Indeed del /Q *.pdb
cl -nologo -O1 -Z7 -LD dll.c -link -OPT:REF
cl -nologo -O1 -Z7 main.c dll.lib -link -OPT:REF There's also a name and type difference between x86 and x64: |
That's the usual underscore prepended to the The latest commit 243f8da adds support for C like symbols, i.e.e that don't have additional mangling. |
That fixes the sample code 👍 |
IIRC cv2pdb doesn't (fully) support DLLs that are relocated to an address other than the default address. If your "main" is actually in a DLL itself that might be the problem. If not, a test case for reproduction might be useful. |
Indeed the dll got relocated. But why would that matter? The pointer to the data is in the exe .idata section. |
One unrelated problem in
diff --git a/src/PEImage.cpp b/src/PEImage.cpp
index 1f916c2..6121a35 100644
--- a/src/PEImage.cpp
+++ b/src/PEImage.cpp
@@ -809,10 +809,11 @@ int PEImage::findSymbol(const char* name, unsigned long& off, bool& dllimport) c
{
IMAGE_SYMBOL* sym = (IMAGE_SYMBOL*) (symtable + i * sizeof_sym);
const char* symname = sym->N.Name.Short == 0 ? strtable + sym->N.Name.Long : (char*)sym->N.ShortName;
- if(symbolMatches(name, symname, dllimport))
+ auto section = bigobj ? ((IMAGE_SYMBOL_EX*)sym)->SectionNumber : sym->SectionNumber;
+ if(section > 0 && symbolMatches(name, symname, dllimport))
{
off = sym->Value;
- return bigobj ? ((IMAGE_SYMBOL_EX*)sym)->SectionNumber : sym->SectionNumber;
+ return section;
}
i += sym->NumberOfAuxSymbols;
} |
I meant the binary you are debugging. If that is an exe, there is no relocation and that's ok then.
I don't think these can appear in the executable. External symbols are only in object files and must be resolved by the linker. |
Well see above, mingw did produce such entries in the coff symbol table. I really don't know where that offset is coming from. IDiaSymbol gives
|
If you provide an example executable, I can have a look.
I guess you are referring to the object file. BTW: The executable I tried with
|
No I do mean the exe as that's where cv2pdb reads the symbol address from. Mine is built with Linux MinGW (via WSL) and dumpbin works. I used
|
Your DLL/EXE still causes the same failure with dumpbin for me (from VS 2019 16.4.4 - edit: I suspect dumpbin is broken for the long section names). If I dump it with
Observations:
|
My dumpbin is from the latest preview. Maybe they fixed something.
Line 1616 in 243f8da
|
Indeed, not sure what I was looking at. The missing offset is 0x1c0000, which is the size of the .bss section before .idata. This section does not exist in the VC compiled executable (although there is a .textbss section as the first section). |
DIA (read via |
The expected pointer is at 0x76b62c. You have to take the aligned sections sizes, or just the differences of the virtual addresses.
I suspect it works because the sections are all of size 0x1000, and the current debug info is off by one section. |
I think I found the reason, the section map seems to be wrong. The bss section entry is set to size 0. diff --git a/src/dwarf2pdb.cpp b/src/dwarf2pdb.cpp
index 70b6fc9..daf2fa7 100644
--- a/src/dwarf2pdb.cpp
+++ b/src/dwarf2pdb.cpp
@@ -1613,8 +1613,8 @@ bool CV2PDB::createTypes()
cbDwarfTypes += addPointerType(dwarfTypes + cbDwarfTypes, type, pointerAttr | 0x20); // needs to be deduplicted?
type = nextDwarfType++;
}
- appendGlobalVar(id.name, type, seg + 1, segOff);
- int rc = mod->AddPublic2(id.name, seg + 1, segOff, type);
+ appendGlobalVar(id.name, type, seg, segOff);
+ int rc = mod->AddPublic2(id.name, seg, segOff, type);
}
}
break;
@@ -1652,7 +1652,7 @@ bool CV2PDB::createDWARFModules()
for (int s = 0; s < img.countSections(); s++)
{
const IMAGE_SECTION_HEADER& sec = img.getSection(s);
- int rc = dbi->AddSec(s + 1, 0x10d, 0, sec.SizeOfRawData);
+ int rc = dbi->AddSec(s + 1, 0x10d, 0, sec.Misc.VirtualSize);
if (rc <= 0)
return setError("cannot add section");
} |
Cool, looks good. I've pushed the fix (the segment should be changed in findSymbol, though). |
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 anygame
variable anymore insidemain
.The main difference in main.o DWARF debug info seems to be
The text was updated successfully, but these errors were encountered: