Finding Variables in C++ Dump
I am trying to locate some variables in a C++ dump. The dump is an SVC dump
of an IMS MPR for a completion code U0240. The variables are defined inside
the function for the class.
For example:
ClassA::functionB (parm1, parm2, parm3)
{
// some variables
int l_iRetColLoc;
// some more variables
...
}
When I look at the storage offset listing for l_iRetColLoc, it says that
its location is at 0(r13). Looks like this means the offset into the
class that it's part of. But since it's not part of a class, it's at
offset 0 into itself.
But what I'm trying to figure out is this: how can I find the offset
into this function's DSA for this variable? I have been going
through the pseudo assembly listing trying to determine this, but it's
hard to isolate this one because the pseudo assembly listing uses variables
names like #SPILL0, #SPILL1, etc.
The doc (LE Debugging Guide) looked promising, but I must have missed
something about finding variables whose scope is local to a function of a class.
Thanks.
Adam Johanson
IMS Systems Programming
USAA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
Yea, it can be a real pain in the butt to actually determine the address.
You can sometimes map the assembly to a line that you can get a clear
indication of which register the address is in. That won't always help with
an existing dump though.
Various ways I do it, although full disclosure: Few if any of these deal
with having an existing dump (although they may help):
1. The easiest is to printf the address somewhere before you need it.
WTOR it if necessary.
2. Next is to look through the function chain to get the address if
it's passed down through any functions
3. (as said above, try to get the address in a register) -- but then
hardware SLIP trap it to get the register address and value in storage
If you have an existing dump, and none of these work for you, your best bet
is to go through storage one reg at a time (perhaps using the assembly as a
best guess starting point), and see if you can map storage around the regs
to data in your whole class instance.
Another thing that I do, btw, is to put eye catchers into each instance and
set them with memset() or similar in the class constructor. Helps immensely.
David Logan
Manager of Product Development, Pitney Bowes Business Insight
http://centrus.com
W: (720) 564-3056
C: (303) 818-8222
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Adam Johanson
Sent: Wednesday, October 08, 2008 17:46
To: IBM-MAIN@BAMA.UA.EDU
Subject: Finding Variables in C++ Dump
I am trying to locate some variables in a C++ dump. The dump is an SVC dump
of an IMS MPR for a completion code U0240. The variables are defined inside
the function for the class.
For example:
ClassA::functionB (parm1, parm2, parm3)
{
// some variables
int l_iRetColLoc;
// some more variables
...
}
When I look at the storage offset listing for l_iRetColLoc, it says that
its location is at 0(r13). Looks like this means the offset into the
class that it's part of. But since it's not part of a class, it's at
offset 0 into itself.
But what I'm trying to figure out is this: how can I find the offset
into this function's DSA for this variable? I have been going
through the pseudo assembly listing trying to determine this, but it's
hard to isolate this one because the pseudo assembly listing uses variables
names like #SPILL0, #SPILL1, etc.
The doc (LE Debugging Guide) looked promising, but I must have missed
something about finding variables whose scope is local to a function of a
class.
Thanks.
Adam Johanson
IMS Systems Programming
USAA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
A variable which is listed in the storage offset listing as 0(r13)
actually never is held in storage, but it resides in a register all the time.
0(r13) simply means that no storage is allocated for this variable (this
is not very nice, I asked the compiler people several times to fix this.
Some compiler versions simply give no offset at all in these cases, only
a line with the variable name and a comma instead of an offset.)
A variable without allocated storage must be a simple local variable
which fits into a register (that is, a pointer, long, int, double etc.).
This is never the case for parameters (they are addressed with r1 and
never transferred by registers, always storage), or parts of a struct,
or variables which need to be addressed by pointer. And, of course,
not for char arrays, decimal values and so on, because they must reside
in storage.
The only way to determine the actual register number is to look at the
assembly code around the error place. If you have something like
x = 0;
*** la r6,0
you know, for example, that r6 is used to hold the value of x.
Kind regards
Bernd
Am Mittwoch, 8. Oktober 2008 23:45 schrieb Adam Johanson:
> I am trying to locate some variables in a C++ dump. The dump is an SVC dump
> of an IMS MPR for a completion code U0240. The variables are defined inside
> the function for the class.
>
> For example:
>
> ClassA::functionB (parm1, parm2, parm3)
> {
> // some variables
> int l_iRetColLoc;
> // some more variables
>...
> }
>
> When I look at the storage offset listing for l_iRetColLoc, it says that
> its location is at 0(r13). Looks like this means the offset into the
> class that it's part of. But since it's not part of a class, it's at
> offset 0 into itself.
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
BTW: if you are in Europe and you want me to hold a class on such things in German or English, please contact me offline. Kind regards Bernd Am Donnerstag, 9. Oktober 2008 09:47 schrieb Bernd Oppolzer: > A variable which is listed in the storage offset listing as 0(r13) > actually never is held in storage, but it resides in a register all the > time. 0(r13) simply means that no storage is allocated for this variable > (this is not very nice, I asked the compiler people several times to fix > this. Some compiler versions simply give no offset at all in these cases, > only a line with the variable name and a comma instead of an offset.) > > A variable without allocated storage must be a simple local variable > which fits into a register (that is, a pointer, long, int, double etc.). > This is never the case for parameters (they are addressed with r1 and > never transferred by registers, always storage), or parts of a struct, > or variables which need to be addressed by pointer. And, of course, > not for char arrays, decimal values and so on, because they must reside > in storage. > > The only way to determine the actual register number is to look at the > assembly code around the error place. If you have something like > > x = 0; > > *** la r6,0 > > you know, for example, that r6 is used to hold the value of x. > > Kind regards > > Bernd > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
2008/10/9 Bernd Oppolzer <[EMAIL PROTECTED]>: > A variable which is listed in the storage offset listing as 0(r13) > actually never is held in storage, but it resides in a register all the time. > 0(r13) simply means that no storage is allocated for this variable (this > is not very nice, I asked the compiler people several times to fix this. > Some compiler versions simply give no offset at all in these cases, only > a line with the variable name and a comma instead of an offset.) > > A variable without allocated storage must be a simple local variable > which fits into a register (that is, a pointer, long, int, double etc.). > This is never the case for parameters (they are addressed with r1 and > never transferred by registers, always storage), or parts of a struct, > or variables which need to be addressed by pointer. And, of course, > not for char arrays, decimal values and so on, because they must reside > in storage. With FASTLINK and XPLINK, some arguments are normally passed directly in GPRs 1-3, and/or FPRs 0-6, and R1 does not point to the argument list. > The only way to determine the actual register number is to look at the > assembly code around the error place. If you have something like > >x = 0; > > *** la r6,0 > > you know, for example, that r6 is used to hold the value of x. Keep in mind that this is not necessarily a fixed assignment, i.e. R6 may hold some other variable at some other point in the code, and some other register may hold the value of x. If you are in a position to reproduce the problem easily, it can make debugging at this low level easier if you compile with all optimizations turned off. And sometimes that even makes the problem go away... :-( Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
Thanks for the responses, guys. Looking closer at the pseudo assembly listing revealed that the compiler was stuffing this variable at +FC into the DSA into a variable that it decided to call "#SPILL2". Since the compiler leaves no comments behind, at least the line numbers can be used to see which machine instructions are for which line of code. >From the pseudo assembly listing: 000248 | * for (l_iRetColLoc = 0; [while condition]; l+iRetColLoc++) Soon after this in the listing: 000248 | STr1,#SPILL2(,r13,252) (R1 has a zero in it from some other variable at this point) 000248 |@78L527 DS0H (label for branching back to top of the loop) And farther down in code: 000248 | L r0,#SPILL2(,r13,252) 000248 | AHI r0,H'1' 000248 | L r14,[EMAIL PROTECTED](r7,r2,0) 000248 | LTR r14,r14 000248 | STr0,#SPILL2(,r13,252) 000248 | BNE @78L527 (only other area where label #78L527 is referenced) Small comment on this... I wish that the mnemonic testing the condition code here was "BNZ" rather than "BNE" since the previous instruction to set the condition code was LTR and the operands will always be equal... Oh well, I'll live. Adam Johanson IMS Systems Programming USAA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
Regarding SPILL area: These compilers first generate kind of intermediate code for an abstract target machine, which has an unbounded number of registers. Most optimizations are done on the code of that abstract machine. These parts of the compiler are portable across all supported platforms. Then, in a second step, the code of the abstract machine is translated into code for the real target machine (for example, z-Arch or Intel or ...). Now the number of registers is limited, so the additional registers (which may have numbers 16, 17, 18, ...) must be simulated in storage, and this is the spill area. So your local variable, although planned to reside in a register, may in the end appear in the spill area, that is, storage. If the target machine would have, say, 32 registers, the additional registers could be "real" registers. BNE vs. BNZ: You know, that this is exactly the same condition mask of the BC machine instruction, do you? I'm teaching ASSEMBLER as well, and the dump classes are not limited to C. They are valid for PL/1 and COBOL and ASSEMBLER programmers, too. Please contact me offline, if you want to hire me to hold a class. Kind regards Bernd Am Donnerstag, 9. Oktober 2008 20:50 schrieben Sie: > Thanks for the responses, guys. Looking closer at the pseudo assembly > listing revealed that the compiler was stuffing this variable at +FC into > the DSA into a variable that it decided to call "#SPILL2". Since the > compiler leaves no comments behind, at least the line numbers can be used > to see which machine instructions are for which line of code. > ... > Small comment on this... I wish that the mnemonic testing the condition > code here was "BNZ" rather than "BNE" since the previous instruction to set > the condition code was LTR and the operands will always be equal... Oh > well, I'll live. > > > Adam Johanson > IMS Systems Programming > USAA > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
>> BNE vs. BNZ: >> You know, that this is exactly the same condition mask of the BC machine >> instruction, do you? Yeah, I was trying to say that BNZ is more intuitive, and it wouldn't have made me verify that they had the same mask. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
