Windbg: Breakpoint SOS, or SOSEX.DLL name of the method - windbg

While debugging with SOS or SOSEX in managed code, I can set breakpoints using !mbm *!*GetSubscription for example, is there any way to get the method name?
Example:
bp 8373772 ".printf \"methodname\";gc".
The idea is to have the name of the methods executed similar like wt -l command does.

You can use !sosex.mln to get the name of whatever, if any, managed object, method, etc. Is located at a given address.

Related

ILE RPG Bind by reference using CRTSQLRPGI

I've been trying a solution for this, but. I cannot find it.
What I'm trying to do, is work with the "bind by reference" ability, but working with ILE RPG written with embedded sql.
I can use the BNDDIR ctl opt in my source. And everything works correctly.
But that means a "bind by copy" method. Checked deleting the SRVPGM and even the BINDDIR. And the caller program still works.
So, is there any way to use "bind by reference" in an ILERPGSQL program?
After my question, an example:
Program SNILOG is a module, that conains several procedures. Part of them, exported.
In QSRVSRC I set the exported procedures, with a source with the same name: SNILOG. Something like this:
STRPGMEXP PGMLVL(*CURRENT)
/************************************************** ******************/
/* *MODULE SNILOG INIGREDI 04/10/21 15:25:30 */
/************************************************** ******************/
EXPORT SYMBOL("GETDIAG_TOSTRING")
EXPORT SYMBOL("GETDIAGNOSTICS")
EXPORT SYMBOL("GRABAR_LOG")
EXPORT SYMBOL("SNILOG")
ENDPGMEXP
As part of the procedures are programmed with embedded sql, the compilation must be done with CRTSQLRPGI, using the parameter OBJTYPE(*SRVPGM).
So, I finally get a SRVPGM called SNILOG, with those 4 procedures exported.
Once I've got the SRVPGM, I add it to a BNDDIR called SNI_BNDDIR.
Ok, let's go to the caller program: SNI600V.
Defined with
dftactgrp(*no)
, of course!.
And compiled with CRTSQLRPGI and parameter OBJTYPE(*PGM).
Here, if I use the control spec
bnddir('SNI_BNDDIR')
, it works fine.
But not fine enough, as this is a "bind by copy" method (I can delete the SRVPGM or the BNDDIR, and it is still working fine).
When I'm not working with SQL, I can use the CRTPGM command, and I can set the BNDSRVPGM parameter, to set the SRVPGM the program is going to be called. Well, just their procedures...
But I cannot find any similar option in CRTSQLRPGI command.
Nor in opt codes in ctl-opt sentence (We have BNDDIR, but not BNDSRVPGM option).
Any idea?
I'm running V7R3M0 with TR level: 6
Thanks in advance!
the use of
bnddir('SNI_BNDDIR')
Is the way to bind by reference OR bind by copy.
The key is what does your BNDDIR look like?
If you want to bind by reference, then it should include *SRVPGM objects.
If you want to bind by copy, then it should include *MODULE objects.
Generally, you want a *BNDDIR for every *SRVPGM that includes the modules (and maybe a utility *SRVPGM or two) needed for building a specific *SRVPGM.
Then one or more *BNDDIR that includes just *SRVPGM objects that are used to build the programs that use those *SRVPGMs.

Is it possible to see smbase in simics?

This post showed me how to see stuff in SMM. And I notice that Simics shows other normally "hidden" registers like the segment descriptor shadow values, which only get updated indirectly. So is it possible to see the "smbase" register in Simics?
To read one MSR, currently you need to use interface calls on the processor. The "%" operator reads named registers on the current processor. Calling the iface inspects any processor object, and works for-only-has-a-number MSRs.
Use online help to figure out how to use the interface. For example:
simics> #conf.board.mb.cpu0.core[0][0].iface.x86_msr.get_number("IA32_TSC_DEADLINE")
1760
simics> api-help x86_msr_interface_t
Help on API keyword "x86_msr_interface_t":
DESCRIPTION
SIM_INTERFACE(x86_msr) {
void (*register_handlers)(
conf_object_t *cpu,
int64 number,
x86_msr_getter_func_t getter,
lang_void *getter_data,
x86_msr_setter_func_t setter,
lang_void *setter_data,
...
Adding a command for inspection is on the wish list.
UPDATE.
The interface also provides the ability to look up from number to name. For the case of MSR 0x9E, IA32_SMBASE, on the "client" core in Public Simics, looking up the name yields this:
simics> #conf.board.mb.cpu0.core[0][0].iface.x86_msr.get_name(158)
'msr_ia32_smbase'
simics> #conf.board.mb.cpu0.core[0]0].iface.x86_msr.get_number("msr_ia32_smbase")
158
For historical reasons, the register is called msr_ia32_smbase, and not IA32_SMBASE from the manual. In general, looking things up by number is a bit more robust. Esp since many MSRs just have numbers in the Simics model as it is currently set up.
First, you may search the loaded configuration for a particular string using the apropos command (a for short). And since smbase is likely exposed via an attribute it would look like a -a smbase. And if there are anything "smbase" in the configuration you will see it.
I loaded the QSP-x86 Firststeps platform and got several hits on the form
<cpu-class>.msr_ia32_smbase
Also, in general it helps knowing the context of a certain something. Such that smbase is "part of" MSR.

How do you get a runtime path for the current file in Racket?

Suppose I have a file called "test.rkt" for which I want to have its absolute path available at runtime. I know that the best way to do this is to bind it using:
(define-runtime-path orig-file "test.rkt")
However, for reflection purposes, I would like to be able to do this without knowing the name of the current file. For example, I would like to be able to do something like:
(define-runtime-path-self orig-file)
You can use #%variable-reference, which (IIRC) is the low-level reflective magic behind define-runtime-path:
(resolved-module-path-name
(variable-reference->resolved-module-path
(#%variable-reference)))
There's also the syntax/location library:
(require syntax/location)
(quote-source-file)
but beware that if you compile the file in one location and then move source file and compiled/ directory to another location, the program will print the location where it was compiled, not where it was run.
There's also a way that goes through syntax objects and module-path-indexes, but that's more complicated.
Does (find-system-path 'run-file) or (simple-form-path (find-system-path 'run-file)) work for you?

Is there a way to find fully qualified method names in WinDbg?

When I want to set a break point using !bpmd, I need the fully qualified method name.
According to the MDSN document ( http://msdn.microsoft.com/en-us/library/bb190764.aspx), I can find type names using ILDASM.
(So I can find fully qualified method names using ILDASM.)
However, this means I need another separate tool just for searching method names.
The background of this question is: I know I can use ‘x’ command for native apps.
As ‘x’ shows symbols, I can find function names easily.
So if there is something like ‘x’ command for .NET apps, I don’t need to use a separate tool.
I usually vaguely remember method names, but I don’t remember fully qualified method names.
As 'x' is to native code, !sosex.mx is to managed code.
Download sosex for free from stevestechspot.com. You can pass wildcards ? and * in your search. If you just want to set a breakpoint, though, you can just use !sosex.mbm (or !mbp, if you want to break on a source file, line number).

how can I modify gvim to follow objects and variables to their definition?

I am used to using (ctrl+click) on Eclipse and following variables/objects to look at the definition in order to understand the code.
I just started my first job and I only have access to unix (vi or gvim). Is it possible to do what I'm looking for?
edit: What I mean by is it possible? Lets say class foo is defined in file foo.hpp and is instantiated in foo.cpp. I want to be able to reach the definition of class foo from any instantiation of it in foo.cpp
With Vim you can use tags files generated by exuberant-ctags and other compatible programs.
"Tags" are function and variables, their name, signature and kind are stored alongside their location in files that Vim is able to parse to allow you to navigate through your code.
:help tags will tell you all you need to know.