Is there a way to change path of pdb file in headers of dll file from absolute to relative?
For example, if I do dumpbin /headers on my library file i get:
Time Type Size RVA Pointer -------- ------ -------- -------- -------- 4AE9A239 cv 4F 0001A9A8 197A8 Format: RSDS, {7B0C89D0-69E1-4A12-817C-424F209FAB10}, 1, D:\Projects\workspace\bin\Release\MyLibrary.pdb
Instead of D:\Projects\workspace\bin\release\MyLibrary.pdb, I want to show only bin\release\MyLibrary.pdb or just MyLibrary.pdb.
I have seen solution for this problem in case of C/C++ assembly but I didn't got any solution for C# assembly although there are many microsoft C# assemblies having this relative path feature.
Does anyone know how to do this?
Yes, possbile via the /PDBALTPATH linker flag.
See more in MSDN
Related
I am new to CMake. In my current project specific directory c file generated object file name need to be modified as below
Ex: foo_lib.c ---> foo_AR_lib.o
foo1_lib.c ---> foo1_AR_lib.o
foo2_lib.c ---> foo2_AR_lib.o
I tried using the file(RENAME <oldname> <newname>) but the original c file is modifying.
So, could you please help on this, the possibilities using any other CMake methods we can achieve this.
I have an AndroidStudio project with 'C' files in. I can compile and run as-is.
My native files are in
src/main/jni/aes
src/main/jni/libjpeg
src/main/jni/smuglib
I am trying to move the source to a location external to the Android studio project so that I can use it from several locations/projects to avoid copy/paste/mistake cycle.
I have defined the include path in CMakeLists.txt
include_directories(src/main/jni/aes src/main/jni/libjpeg src/main/jni/smuglib)
And have specified the files in the add_library command
add_library( # Sets the name of the library.
native-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
src/main/jni/aes/aes.c
src/main/jni/smuglib/smuglib.c
.... etc
How do I set up a variable to refer to these paths, eg 'src/main/jni/aes' so that I can use it in both the include and in the source list?
I tried variations on
set(aes_src, src/main/jni/aes)
but uses of it as ${aes_src} either in the include path statement or in the source list give me all sorts of arcane errors which I am at a loss to understand.
I will generate some of these and include them if folk think it would help, but I am likely barking up the wrong kettle of fish with this approach.
Is there a better approach?
It is set(VAR_NAME item1 item2 item3). No commas needed.
I have next workflow:
1) Build dll and pdb files.
2) Share dll to cutomer
3) Analize memory dump from customer.
When I run !analyze -v in WinDbg I got (below part of output)
....
MANAGED_STACK_COMMAND: _EFN_StackTrace
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
// some callstack here
MODULE_NAME: RTPLogic
IMAGE_NAME: RTPLogic.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 58a43706
STACK_COMMAND: ~541s; .ecxr ; kb
FAILURE_BUCKET_ID: WRONG_SYMBOLS_c0000374_RTPLogic.dll!CSRTPStack::Finalize
BUCKET_ID: X64_APPLICATION_FAULT_WRONG_SYMBOLS_rtplogic!CSRTPStack::Finalize+1da
Looks like we have wrong debug symbol for RTPLogic.dll.
I download ChkMatch tool.
I get pdb path from windbg
0:541> !lmi RTPlogic.dll
Loaded Module Info: [rtplogic.dll]
Module: RTPLogic
.....
Age: 1, Pdb: D:\Work\path_to_original_pdb\RTPLogic.pdb
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from image header.
C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb
I have logs related to this dump and I see that my changes appears in logs. So customer not forgotten to install my DLL before get the memdump.
I run ChkMatch
PS D:\tools> .\ChkMatch.exe -c "D:\Work\path_to_dll\RTPLogic.dll" "C:\Progra
mData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb"
.....
Result: Matched
How it possible that I got wrong debug symbols in such situation?
The symbols for RTPLogic.dll!CSRTPStack::Finalize are correct, but other symbols that are required to reconstruct the call stack are incorrect. It's likely that you have some operating system methods on the call stack and the symbols for ntdll or similar are missing.
Since with ChkMatch, you're only checking one single PDB file, the result of ChkMatch is as reliable and correct (for one PDB) as that of WinDbg (for many PDBs) and they do not contradict each other.
Your sympath probably contains only a local path to your own DLLs and does not contain any information about Microsoft's symbol server. In the output of .sympath (which you did not post), I expect to see something like
0:000> .sympath
D:\Work\path_to_dll
You should include Microsoft symbols as well, as described in How to set up symbols in WinDbg. To fix the problem, use the following commands:
.symfix+ c:\symbols
.reload /f
The output of .sympath should now look like
0:000> .sympath
D:\Work\path_to_dll;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
This should help WinDbg in reconstructing the complete call stack, resolve OS methods of ntdll and others and thus get rid of the "wrong symbols" message.
the usual installation descriptions tells me that I need to run Pharo at least three files:
image file
changes file
source file (e.g. PharoV10.sources)
I've run Pharo 2 without the sources file and i didn't see any problem. All sources seemed to be avaiable.
So, why do I need the sources file (e.g. PharoV10.sources)?
The image file contains only the compiled code, not the original source code. The changes file contains source code for the stuff that you added to the system yourself but not source code for existing system classes. To get the source code for existing system classes you need the sources file.
Having said that, Smalltalk can decompile the code and produce what looks like source code if the sources file isn't available. This code will be missing proper variable names, comments and spacing. You really don't want to use decompiled source code so you need access to the sources file.
3 possible explanations, try to identify the joke:
the Browser is smart enough to show you a source reconstructed (Decompiled) from the CompiledMethod byte codes. Hint: in this case, you loose all comments
there is a search path for the sources files, and one is found somewhere on your disk
Pharo is changing so fast that every source is now found in the .changes file
For verifying 1., you could try to browse references to Decompiler (there are a bit too many uses to my own taste).
For verifying 2., you could start browsing implementors of #openSourceFiles
For verifying 3., you could evaluate this snippet:
| nSources nChanges |
nSources := nChanges := 0.
SystemNavigation default allBehaviorsDo: [:b |
b selectorsDo: [:s |
(b compiledMethodAt: s) fileIndex = 1
ifTrue: [nSources := nSources+1]
ifFalse: [nChanges := nChanges+1]]].
^{nSources. nChanges}
It is also possible that Pharo downloads PharoV10.sources automatically.
I have a dll that exports
extern "C" __declspec(dllexport) int __stdcall Foo( void );
A dump of the dll shows
******************************************************************************
Section: Exports
File Offset: 00001400 (5120)
Flags: 00000000
Time Stamp: 00000000
Major Version: 0000
Minor Version: 0000
Exports from simple.dll
3 exported name(s), 3 export addresse(s). Ordinal base is 1.
Sorted by Name:
RVA Ord. Hint Name
-------- ---- ---- ----
00002104 3 0000 std::nothrow
00001258 2 0001 Foo
000020F8 1 0002 ___CPPdebugHook
******************************************************************************
I started with the following def file:
LIBRARY simple.dll
EXPORTS
Foo
This created a lib file with the following exports:
Exports
ordinal name
_Foo
When I link with this library, the msvc linker complains that it can't find _Foo#0. To correct this problem, I added an alias to the def file.
LIBRARY simple.dll
EXPORTS
Foo
Foo#0=Foo
Which results in a lib file with exports
Exports
ordinal name
_Foo
_Foo#0
Now the project links without any problem. However, when I try to run it, I get the message
"The procedure entry point Foo#0 could not be located in the dynamic link library simple.dll"
So it appears that even though I told lib.exe that Foo#0 is an alias for Foo, it still creates an import library that tries to load "Foo#0" by name.
Is there a way to get the import library to load "Foo" when I asked for "Foo#0"?
Thanks,
David
You had the right idea trying to use an alias ...
"it seems LIB does not accept aliased forms (it will simply ignore the part after the equal-sign); 2) it assumes all functions in the DEF file __cdecl. The second point lies in the fact that the import library it produces will map each symbol in the DLL to an internal name with an underscore prefixed, i.e., the linker using the import library will try to resolve an undefined symbol _Function to the symbol Function in the DLL. It takes no special care of the __stdcall calling convention. With some techniques we could use LIB to produce import libraries for __stdcall functions, but the caller could only call them by ordinal, not by name. The details are left as an exercise :-)." (http://wyw.dcweb.cn/stdcall.htm)
Instead of using an alias use an ordinal: (using your example):
LIBRARY simple.dll
EXPORTS
Foo
Foo#0 #2 ;(from your dumpbin)
Worked for me :)