I see some references and tutorials about the commnads of WinDBG.
Some of them like this lm, this .echo, this !running, and this nt!_PDB.
What is difference between these categories
xxx
.xxx
!xxx
xxx!yyy
?
They look so confused.
There are built-in commands, meta commands (dot commands) and extension commands (bang commands).
My personal opinion is that you needn't care too much about the difference of built-in commands compared to meta commands, since there are enough examples where those definitions do not match properly. It's sufficient to know that they are always there and don't need an extension to be loaded.
Good examples for built-in commands, which are mainly about controlling and getting information from the debugging target:
g - go
k - call stack
~ - list threads
Examples where IMHO this definition does not really match:
version - show version of the debugger
vercommand - show command line that was used to start the debugger
n - set number base
Good examples for meta commands, which are thought for only affecting the debugger but not the target:
.cls - clear screen
.chain - display loaded extensions
.effmach - change behavior of the debugger regarding the architecture
.prefer_dml - change output format
Example where IMHO this definition does not really match:
.lastevent - show last exception or event that occurred (in the target)
.ttime - display thread times (of the target)
.call - call a function (in the target)
.dvalloc - allocate memory (in the target)
However, it's good to understand that the extension commands are different, especially because the same command may result in different output, depending on which extension is loaded or appears first in the extension list and that you can affect the order (e.g. by .load, .unload, .setdll). Besides the simple form !command, note that there is also the !extension.command syntax to specify the extension explicitly. I'll use it in the example below. (There's even !c:\path\to\extension.command)
The example of a collision of extension commands is given from a kernel debug session where one !heap does not give any output and the other obviously needs a parameter to work.
0: kd> !ext.heap
0: kd> !exts.heap
Invalid type information
The last format mentioned in your question (xxx!yyy) is not a command, but a method or type information where xxx denotes the module (DLL) and yyy denotes the method or type name. Often, this is also seen with an additional offset in bytes for locations inside the method (xxx!yyy+0xhhh)
See the following:
xxx - these are built in commands
.xxx - these are meta commands
!xxx - these are extension commands, so they call a command from an extension dll
xxx!yyy - this looks the syntax to reference an exported function from a dll:
<dll_name>!<method_name>
You may find the following useful: http://windbg.info/doc/1-common-cmds.html
Related
I would like to prefix my drivers (debug) output with its name, i.e. [myDriver] Actual message. Since it is tiresome to write printk(level NAMEMACRO "Actual message\n") every time I was thinking of overwriting printk/pr_* to actually include the [myDriver] part. However I can not think of a way to do this. In the best case the solution would not force me to change the printk/pr_* calls in the code (With changed calls this becomes trivial).
Is this possible? (Since I included other headers which in turn include the printk header it will always be defined this rules out not linking to the original as suggested in a different so answer)
Are there any reasons why current drivers do not at this to the text? (Is there another way to filter dmesg by driver?)
I am somewhat aware of dev_dbg but I have not found anything dev specific for warnings in general so I will use printk/pr_err for that.
Its standard to use pr_{debug,warn,err}() with [drivername] prefixed.
ex:
pr_debug("kvm: matched tsc offset for %llu\n", data);
Alternatively you can use dev_warn()
ex:
dev_warn(&adap->dev, "Bus may be unreliable\n");
Is there another way to filter dmesg by driver?
Not unless you want to run dmesg -c to clear the logs, before getting the your driver loaded. Its always recommenced prefixing the driver name in your debug / print messages. As when you receives logs from customers, you don't want to waste time reading through each line manually.
The relevant answer (found in the duplicate) is to #define pr_fmt (code from the duplicate question linked above):
/* At the top of the file, before any includes */
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/printk.h>
As an additional note, if I include variables, sometime pr_fmt is not automatically applied for me. Manual use as in printk(pr_fmt("message %p"), (void*)ptr) fixes those occasions, and adheres to the convention of defining pr_fmt
Since I did not find the duplicate question, I will not delete this question for other googlers like me.
gdb provides a command "print localx" which prints the value stored in the localx variable. So, it basically must be using the symbol table to find the mapping (localx -> addressx on stack). I am unable to understand how this mapping can be created.
What I tried
I studied the intermediate temporary files of gcc using -save-temps option, and observed that a local variable local1 was mapped to a symbol name "LASF8". However, the objdump utility tool did not show this symbol name.
Context :
I am working on a project which requires building a pin-tool to print the accesses of local variables. Given a function, I would like to say that this address corresponds to this variable name. This requires reading the symbol table to correspond an address to a symbol table entry. GDB does the exact reverse mapping. Hence, I would like to understand the same.
The symbol table is contained in the debugging information. This debugging information is emitted by gcc -g. gdb reads the debugging information to get symbolic information, among other things.
Typically the debugging information is in DWARF format. See http://www.dwarfstd.org/ for the specification.
You can also see DWARF more directly using readelf. For example readelf -wi will show the main (".debug_info") debugging information for an ELF file.
Note that doing the mapping in reverse -- that is, assigning a name to every stack slot -- is not entirely easy. First, not every stack slot will have a name. This is because the compiler may spill temporaries to the stack. Second, many locals will have DWARF location expressions to represent their location. This means you'll need to write an expression evaluator (not hard but also not trivial); you could conceivably (unlikely in practice but possible in theory) run into expressions which cannot be evaluated without a real stack frame; and finally the names will therefore generally only be valid at a given PC.
I believe there's a feature request in gdb bugzilla to add this feature to gdb.
I'm encountering my second problem in three days where an errant binding is causing me hours of searching and headaches.
A glance at the stack trace indicates a problem with debugging (e.g., one of the last methods called before the runtime started generating an exception was bind:toObject:withKeyPath:options:). However, I'm finding it impossible to determine WHICH binding is causing the problem:
Nothing in the stack trace or variable inspection indicates which views were involved in the call that crashed.
The last non-machine instruction that's traceable by stepping through code is a call to a monolithic function (awakeFromNib or makeKeyAndOrderFront).
The message in the actual exception is mystifying - e.g., "Cannot create NSArray from object of class NSScrollView," while creating a window that doesn't have any NSScrollViews (just two buttons and two text fields).
So... any tips for debugging these types of problems? For example:
Is there any way to get a list of ALL of the bindings specified in a nib/xib? (The inability to do this drives me CRAZY!)
Is there any way to find out which views or controls were involved in the crash?
Is there any way to get more information about what's happening inside monolithic calls like awakeFromNib?
You can open the xib file as source code (not in IB) and search for "IBBindingConnection" sections.
Example: Justin's way to search (see comments):
grep -A 18 -B 1 -H -a -n "IBBindingConnection" /PATH/TO/NIB
I am using Eclipse CDT (Helios release) to edit the source code of an (old) C application, which also uses ESQL. In this project, by convention, files containing ESQL code have a .sc extension (instead of the default .c)
All ESQL sections e.g. starting with EXEC SQL keywords are flagged as “syntax error” (vertical ruler, overview ruler and amber squiggly line). The actual compilation is performed on a different machine (Unix), which has the ESQL compiler. What can I do to check the syntax of the SQL code on the development machine?
Note: I can hide the notification from Preferences / General / Editors / Text Editors / Annotations / C/C++ Indexer Markers but this may hide possible useful warnings.
What you have isn't C code, in spite of what you might think.
Extra "syntax" (e.g, EXEC SQL plus whatever is inside) simply isn't C code, and any tool that processes conventional C code will by necessity reject it as a syntax error.
The "ESQL processor" (sounds like a mainframe given the EXEC SQL phrase) probably preprocesses what you are thinking of a C code to extract the SQL and replace it by function calls; that result is likely fed off to a real C compiler.
I doubt you can do anything useful with this using CDT.
If you use the Window->Preferences->C/C++->File Types and define a new file type with C or C++ as *.pc, or *.sc etc. as is appropriate to your extension, then the syntax highlighter will attempt to colour the keywords appropriately and provide hover tips. Of course the EXEC SQL type statements will show up as errors but those are relatively easy to ignore knowing that you're looking for some help for the elements in the file, but not all (i.e. doesn't parse embedded SQL).
Update (for vi(m) lovers): I found that I needed to create a file in ~/.vim/ftdetect/pc.vim containing:
au BufRead,BufNewFile *.pc set filetype=pc
and I also created a link from my /usr/share/vim/vim73/esqlc.vim to pc.vim (though we could have specified *.pc set filetype=esqlc)
and I installed vrapper, then after restarting eclipse, I my EXEC SQL or other keywords were no longer underlined, though they weren't colourized either. That may change in future vrapper updates. (Note: I'm using Eclipse Kepler as it supports vrapper)
Bonus: make sure to set your preferences for "Find and Replace" to CTRL-4 instead of CTRL-F to get page forward in vim working.
Are file descriptors supported on windows? Why do things "seem to work" in Perl with fds?
Things like "fileno", "dup" and "dup2" were working but then randomly inside some other environment, stopped working. It's hard to give details, mostly what I'm looking for is answers from experienced Windows programmers and how file descriptors work/don't work on Windows.
I would guess that it's the PerlIO layer playing games and making it seem as though file descriptors work, but that's only a guess.
Example of what is happening:
open($saveout, ">&STDOUT") or die();
...
open(STDOUT, ">&=".fileno($saveout)) or die();
The second line die()s but only in certain situations (which I have yet to nail down).
Windows uses file descriptors natively. See Low-Level I/O on MSDN. They all report errors through the C variable errno, which means they show up in Perl's $!.
Note that you can save yourself a bit of typing:
open(STDOUT, ">&=", $saveout) or ...;
This works because the documentation for open in perlfunc provides:
If you use the 3-arg form then you can pass either a number, the name of a filehandle or the normal “reference to a glob.”
Finally, always include meaningful diagnostics when you call die! The program below identifies itself ($0), tells what it was trying to do (open), and why it failed ($!). Also, because the message doesn't end with a newline, die adds the name of the file and line number where it was called.
my $fakefd = 12345;
open(STDOUT, ">&=", $fakefd) or die("$0: open: $!");
This produces
prog.pl: open: Bad file descriptor at foo.pl line 2.
According to the documentation for _fdopen (because you used >&= and not >&), it has two failure modes:
If execution is allowed to continue, errno is set either to EBADF, indicating a bad file descriptor, or EINVAL, indicating that mode was a null pointer.
The second would be a bug in perl and highly unlikely because I don't see anywhere in perlio.c that involves a computed mode: they're all static strings.
Something appears to have gone wrong with $saveout. Could $saveout have been closed before you try to restore it? From your example, it's unclear whether you enabled the strict pragma. If it's not lexical (declared with my), are you calling a function that also monkeys with $saveout?