I'm trying to use windbg more, and I keep having problems with the symbol cache. It isn't clear to me what the format of the string is supposed to be.
I have a few requirements:
use Microsoft's server http://msdl.microsoft.com/download/symbols
use symbols from our software that are archived at \\foo\Build1234
use a local cache at c:\dev\symbols
The archive of symbols from our distributed build at \\foo\Build1234 are not organized as a symbol server. If I understand it correctly, I need to use the cache keyword.
Given these requirements, does this look like a properly formatted srvpath:
cache*\\foo\Build1234;srv*c:\dev\symbols*http://msdl.microsoft.com/download/symbols
Edit:
I just started reading Advanced Windows Debugging and I had misinterpreted how the cache keyword works. I thought it was a way of telling the debugger that the folder is just a folder of files and not a symbol server. After Michael left his comment, I reread the section and see that it indeed works as Michael described.
Now I'm confused by when you use a ; or a * to separate paths/URLs. And when you need the srv* prefix. In the online help for windbg they give this example:
\\someshare\that\cachestar\ignores;srv*c:\mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:\mysymbols;\\anothershare\that\gets\cached
The symbols from \\someshare are not cached, symbols from Microsoft are cached in c:\mysymbols, and c:\mysymbols is used as the cache for any other paths to the right of the cache* directive.
The occasional use of srv* is confusing me -- I don't understand why the first and last paths aren't prefixed with srv*.
Edit 2:
This is slowly starting to make sense to me. The srv directive is used for symbol servers, and not for normal symbol directories. So, I believe the answer to my original question is this:
\\foo\Build1234;cache*c:\dev\symbols;srv*http://msdl.microsoft.com/download/symbols
SRV*C:\dev\symbols*http://msdl.microsoft.com/download/symbols;\\foo\build1234
Should work fine, if \\foo\build1234 is just flat PDB's. Cache isn't needed here; you just need to add the directory to your symbol path.
The cache keyword specifies where you want to cache your symbol files, and is useful for caching symbols locally from non-indexed shares (like \\foo\build1234)
cache*C:\dev\symbols;SRV*C:\dev\symbols*http://msdl.microsoft.com/download/symbols;\\foo\build1234
The above path would store symbols from MS's symbol server and your symbol share to your local machine in C:\dev\symbols.
To debug symbol issues using windbg, do
!sym noisy
.reload <some exe or DLL in your session>
And then do some action that would force the PDB to be loaded. You'll see where windbg is looking for files, and if it rejects a PDB why it did so.
!sym quiet
Will then suppress symbol prompts.
Here's a detailed post on debugging issues with symbols loading.
Loading symbols in Windbg
Related
I uploaded Fabian Vogt's micropython port to my TI Nspire CX CAS, together with a couple of *.py.tns files to try. I can't find a way to load/launch those files.
As micropython does not include the os module, I can't use os.chdir to change the current directory and load the *.py files from the python shell. I tried from python shell: open("documents/mydirectory/myfile")
with different extensions .py or .py.tns, without success.
I don't think the Nspire has anything like the terminal commmand line either.
Thanks for your help,
There are 2 ways that you could do this, one easy way and one tedious way.
1. Map .py to micropython in your ndless.cfg
(ndless.cfg should be at /documents/ndless/ndless.cfg)
Like so:
ext.xxx=program-name
ext.xxx=program-name
ext.txt=nTxt
ext.py=micropython
ext.xxx=program-name
ext.xxx=program-name
You can edit this file either by copying it back and forth from your computer using TiLP or the official software, or you can edit it on-calc using nTxt. (This requires a bit of fiddling with making a copy of ndless.cfg so that the mappings still exist to open the copied file ndless.txt).
Ndless should come with a standard ndless.cfg containing basic bindings for nTxt and a few popular emulators. If you don't have one, get the standard one here. It will scan all directories (at least /documents/*, AFAIK) for programs. I've found that removing lines related to programs not on your Nspire will decrease load time.
2. Proper way to run a file in Python
To run a file in Python, you should do something like this:
with open("/documents/helloworld.py.tns","r") as file:
exec(file.read())
This will properly close the file after executing, which I've noticed is quite important on the Nspire, as leaving files open has given me trouble before. Of course, if you'd like, you can do exec(open("...","r").read()) and then handle closing the file yourself, but be warned: bad things can happen if you forget.
Also, you must remember to add the leading / and the .tns extension, or else strange things will happen, especially with writing to files.
That's about it! Feel free to ask more questions if needed, I'll be watching the ti-nspire tag.
(Just realized this question is quite old, but I guess it still might be helpful for others who end up on empty questions months later while trying to figure something out :P)
I'm using VSCode + CodeLLDB + LLDB to debug a JIT'ed language (KL), however I'm having trouble getting LLDB to recognize the source files.
This is a duplicate question to LLDB equivalent of gdb "directory" command for specifying source search path?, however it's accepted answer doesn't work for me.
LLDB seems to think every source unit is compiled to the local directory - so if I execute
kl /MyWork/someFile.kl
and this file includes /any/other/path/external.kl, LLDB will believe the file is located as /MyWork/external.kl
So far, I'm (mostly) working around this problem by using
settings set target.source-map /MyWork/ /any/other/path/
However this only seems to work for a single folder. If I tried:
settings set target.source-map /MyWork/ /any/other/path/
settings set target.source-map /MyWork/ /I/use/many/dependencies/
Then LLDB seems to not be able to find -any- files in either folder. Interestingly, when I tried this LLDB errored with accurate messages
can't find external.kl in /I/use/many/dependencies/
can't find dependencies.kl in /any/other/path/
Which are accurate messages, but seems almost as if LLDB is just looking for an excuse to error-out :).
Note - I can set breakpoints and view locals, I just can't seem to view the source code at that spot.
Anywho - is there any suggestions on how to deal with this issue? There are 3 possibilities to work with:
- Modify/work with LLDB to find the source files
- Modify CodeLLDB to modify paths between LLDB + VSCode
- Somehow convince VSCode to ignore the path given to it, and search its own folders for any file matching the name.
My suspicion is that LLDB is the right place to fix this, but I am open to any suggestions (right up to the point of linking each and every source file into a flat folder I can redirect to).
lldb only knows about source paths from what is written in the debug information. The rule in DWARF (the debug format lldb uses) is that if an include file is just given by relative path or base name then it is taken to be relative to the compilation directory. Looks like that's what is happening in your case. That sounds like a compiler bug. lldb's not going to be able to reconstruct the file hierarchy at this point.
The source maps should give you a manual way to fix this, and from the sound of it, what you are describing should work. But maybe there's something else odd in the DWARF output from kl that is confusing it. You'll need to file a bug with some example binary to http://bugreporter.apple.com.
So I noticed, while answering this question, that the one who asked the question appears to be a javascript developer. And as the code I wrote in haskell is easy enough, I thought I give haste a try and try to compile it to javascript.
So, I downloaded the Windows binary package of haste (why does the .msi require a reboot?!!?), added it to my path, issued haste-cabal update and haste-cabal install split and after a bit of reading the output of hastec --help, I issued:
PS E:\h\stackoverflow> hastec -o hexagon.js --pretty-print hexagon.hs
as my best guess on how to get the output I am looking for.
Opposite to my expectation, haste output was this:
hastec.exe: user error (shell expression failed in readModule: Data.Binary.Get.runGet at position 8: not enough bytes)
So, my question: What do I have to do to get a java script source file?
Is it possible that you have an old version of Haste lying around, or have intermediate files (.jsmod, for instance) from a different version of the compiler in your source directory? This sounds like the (quite unhelpful) error message Haste produces when it runs into a corrupted intermediate file.
Check that the version of the binary you're calling is what you expect (hastec --version). Then, try getting rid of all intermediate files in the directory as well as any files in %USERPROFILE%\AppData\Roaming\haste, reinstalling split, and recompiling with the -fforce-recomp flag. You should also add a main function, so that Haste has an entry point to your program from which to start linking. If all you want to do is to make some Haskell function available to external JavaScript, you can use the export foreign function interface:
{-# LANGUAGE OverloadedStrings #-}
module Main where
import Haste.Foreign
import Hexagon
main = export "picture" Hexagon.picture
You will probably also want to compile your program with the --onexec flag, to make sure that main runs and exports picture immediately when loaded, and not on page load which is the default:
> hastec -o hexagon.js --pretty-print --onexec hexagon.hs
After doing this, any code included after hexagon.js will be able to call e.g. Haste.picture(5); in order to produce a picture of size 5.
(Re: MSI installer requiring a reboot, this is required since it adds the Haste binaries to your %PATH%, which does not take effect immediately. I assume that a re-login would be enough to make it take effect, however.)
For example, in my main.scm file I have (load "util.scm"). util.scm is a file in the same folder as main.scm. Both files are located in ~/documents/myproject/.
Now when I'm in this directory, and I run $ chez-scheme main.scm everything works fine. However, if I'm in my home directory and run $chez-scheme documents/myproject/main.scm it complains, not being able to find the file util.scm. I suppose this is the case because the current directory was my relevant home directory, and as such util.scm is indeed not there, it is actually in documents/myproject/. That being said, I'm used (in other languages) to the functionality of looking these paths up relative to the file containing the instruction to import, and I'd like to have that here as well. I've tried prefixing it by ./ or defining the file as a libary and doing (import (util)) but none of it works outside of documents/myproject/. Is there any way to get this to work as I intend it to?
I assume this is Chez-Scheme-specific. If not I'd prefer an answer that is implementation-neutral.
load is kind of awkward in R5RS since the report states that system interfaces are off topic in the report, but they include load which is a half hearted solution. The report does not say if the load is relative to the current directory or the file the load form originates from so in order to be portable I guess you are required to run your script from the current directory and have your loaded file relative to both.
Since Chez Scheme implements R6RS load is not really the right form to use. R6RS removed load in favor of libraries. You should make your file a library and consult how to install it. In some systems that is just placing the files in the right path, adding library location in configuration or running install script. How one uses the library is the same in all implementations, by using import.
According to Chez documentation you can pass --libdirs to it to give it one or more paths to consider for loading libraries. You can see the paths it scans by evaluating (library-directories)
There are several different ways to accomplish what (I think) you are trying to do, but eventually they all boil down to letting Chez know where to look for things. When given relative paths, include and load use the source-directories parameter to search for the requested file. Libraries have their path automatically prepended to source-directories while they are being loaded or compiled, so if your main.scm were a library definition then it would find util.scm as you expect.
However, it sounds like main.scm isn't a library, it's a top-level program. Unfortunately, Chez doesn't have a command line option to set the source-directories like it does for library directories. That leaves you with a bit less flexibility. Any of the following will work:
Make util.scm a library and invoke Chez with the --libdirs option to let it know where to look for libraries.
Set source-directories and load main.scm from inside the REPL rather than from the command line.
Write a wrapper shell script that does the above by echoing the commands into scheme so you don't have to type it yourself. (Only suitable if you don't also need to then type into the scheme session).
Write a wrapper shell script that cds into your project directory before running scheme (and presumably cds back to the original directory when it's done).
I am trying to figure out what hashing algorithm is used for the Microsoft Symbol Local Cache directory.
For example, the local cache can be something like the following
L:\Symbols
\browseui.dll
\44FBC679fe000
browsue.dll
\browseui.pdb
\44F402F62
browseui.pdb
\explorer.exe
\3EBF1F14f7000
explorer.exe
\explorer.pdb
\3EBF1F141
explorer.pdb
\msvcr71.pdb
\60D915C6AB6A4F3586E9096E2F8856482
msvcr71.pdb
There seems to be some sort of correspondence between a file and its debug database. Other than that, I can’t figure out how the names of these (presumably) hexadecimal string folders are being generated.
Some of them are 9 digits, some 13 digits, and others are 33 digits. It looks like an actual, live-file (which for some reason is stored in the symbol cache) has a 13-digit hash while its (nearly similar) debug database gets a 9-digit hash. Some debug databases get a 13-digit hash; can’t figure out what makes these ones special, although they don’t have a corresponding live-file.
I’ve tried hashing the files with every kind of hash algorithm that I know of (39 of them) and none match in any way (straight up, reversed, alternate endian’d, etc.)
Any ideas?
Update
I think I finally found it. From Symbol Storage Format:
SymStore uses the file system itself as a database. It creates a large tree of directories, with directory names based on such things as the symbol file time stamps, signatures, age, and other data.
Edit
Dang, unfortunately it only mentions that the directory name is derived from various aspects (not quite a hash I guess), but does not say exactly how. The search continues… :-(
This page has info on calculating the IDs for the symbol files as well as executables/DLLs.
Basically, for executables and DLLs, you extract the timestamp and filesize from the PE header as listed in the page that Griff linked to. For PDB files however, you will need the DBH command from the Windows Debugging Tools. Simply load the PDB file into DBH and use the INFO command to get the PdbSig/PdbSig70 and PdbAge. Bam! That’s it.
I just created the appropriate folders for the PDB files that I had in my SYSTEM32 folder for some reason, and finally moved them to the local symbol store.
Try looking at this page: Symbol Server Callback Function
EXE/DLL directory name is created by concatenating hex string of the "file modified" time-stamp and "SizeOfImage" from IMAGE_OPTIONAL_HEADER
Finding PE files
The format for the path to a PE file in a symbol server share is:
"%s\%s\%08X%x\%s" % (serverName, peName, timeStamp, imageSize, peName)
Example:
https://msdl.microsoft.com/download/symbols/ntdll.dll/B29ECF521f0000/ntdll.dll
Finding PDB files
The format for the path to a PDB file in a symbol server share is:
"%s\%s\%s%x\%s" % (serverPath, pdbName, guid, age, pdbName)
Example:
https://msdl.microsoft.com/download/symbols/ntdll.pdb/4BC147AE72E8D05022366D6570A8E3461/ntdll.pdb
Source: Symbols the Microsoft Way by Bruce Dawson.
You can find the answer,
SYMBOL RETRIEVER SHELL EXTENSION
; http://www.vitoplantamura.com/index.aspx?page=symretriever
DebugDir.cpp
; http://www.debuginfo.com/examples/src/DebugDir.cpp
PDB File Internals
; http://www.informit.com/articles/article.aspx?p=22685