Post by ***@gmail.com [hercules-390]This more of a Visual Studio question. The Sysblk global structure
is a entry in hsys.c part of hsys.dll
When stepping thru in Visual Studio apparently because of the Way
the Code is built there aren't any debug symbols and I can display
the values of anything decalred in sysblk
Correct. This is a Visual Studio debugger issue and NOT a Hercules issue.
You are also correct that it is because SYSBLK is part of a different module (hsys.dll) and not the one you happen to be instruction stepping through at the time (e.g. hengine.dll).
But you are incorrect that there aren't any debug symbols and I can display. There are. You just have to use the special context operator syntax that tells the Visual Studio which module the symbol is in:
{,,hsys.dll} sysblk
{,,hsys.dll} sysblk.arch_mode
This tells the debugger variables you are trying to display are in the hsys.dll module. It's a pain in the butt to have to specify the context operator each time you want to display a SYSBLK variable, but I know of no other way.
With older versions of Visual Studio (e.g. Visual Studio 2008) you must specify the full context operator syntax: open brace, context values separated by commas, closing brace followed by the variable name.
In later versions of Visual Studio it looks like they've added support for a special syntax to be used exclusively for when the variable in question is in another module (which is the most reason by for having to use the context operator in the first place): module name, exclamation point, variable name:
hsys.dll!sysblk
hsys.dll!sysblk.arch_mode
Here are the web pages that document Visual Studio's context operator:
https://msdn.microsoft.com/en-us/library/wztycb7f(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/y2t7ahxk.aspx
I wish there was a way (e.g. some plugin or addin that could be written for example) to automate this task instead of having to always manually use the context operator each time, but alas I haven't had time to research it.
Hope that helps!
p.s. Setting tracepoints(*) instead of breakpoints is also a very value debugging technique. It's like having the debugger automatically do a 'logmsg' for you to display variable values and then continue without actually stopping or breaking. I've used them many times.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
(*) https://blogs.msdn.microsoft.com/devops/2013/10/10/tracepoints/
Below is an excerpt from my personal "Visual Studio Tips and Tricks" file:
-------------------------------------------------------------------------------
You can have a breakpoint issue a MESSAGE instead of breaking:
Set the breakpoint, then right-click and select "When Hit".
To print the value of a variable, use {varname}.
To print the value of a variable in HEX, use {varname,x}.
Special variable names (do NOT surround with braces!) are:
$ADDRESS current instruction address
$FUNCTION current function name
$CALLER previous function name
$CALLSTACK (all previous function names?)
$PID process id
$PNAME process name
$TID thread id
$TNAME thread name
$TICK current tick count
$FILEPOS current file position (i.e. line number!)
ALSO NOTE that depending on where your variable actually exists,
you might also need to use the debugger context operator syntax:
e.g:
{{,,external.dll}varname}
Refer the the "context operator" topic in Visual Studio documentation
as well as my own document called "_Debugger Context Operator.txt"
-------------------------------------------------------------------------------