The BRC 7,*+36 is only going to branch if the condition code bits are 7.
LLGC doesnt change the condition code, so it would be set off a different
instruction.
Joe
On Mon, Jan 11, 2021 at 9:20 PM Dennis Fitzpatrick <den...@dcfitz.com>
wrote:
> Thanks for the string.h reference as that seems to have picked up the
> missing __MEMSET. I'm going to go back to my larger library of functions
> with my own header complications that wrap all of this up, and apply this
> and see what happens. I'll report back on that.
>
> You show option of LP64 with is a 64 bit compile while I'm defaulting to
> 32 bit. The sizeof as pointed out was incorrect but fortuitous since
> sizeof(xarg) is 4 (a 4 byte pointer) and the length I wanted to compare is
> 4 bytes. I should have just hard coded it for the sample. The Metal C
> library memcmp routine I show in the disassembly I believe still in error
> because it increments and then loads the data after the string runs out.
> That's the two LLGC instructions after BCR 7. They load the next bytes
> before testing in the BRCT that the memory area has run out. It computes
> the result value by subtracting the two bytes after the end of the memory.
> When I was calling the library routine nothing worked because of that. If I
> let it use to the builtin.h code my converted programs worked. I hope that
> makes sense.
>
>
>
>
> Dennis C. Fitzpatrick
> den...@dcfitz.com
> H: 630.325.6184
> W: 630.325.6137
> M: 630.660.8040
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf
> Of Joe Monk
> Sent: Monday, January 11, 2021 6:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Compile error and also possible library bug with Metal/C
> metal.h
>
> "I'd be perfectly happy for someone to tell me I missed some obvious
> compiler option or did something else really stupid."
>
> Found this on another website ...
>
> The issue was with the search order. Although I did
> search(/usr/metal/include) from with in my JCL I didn't proceed it with a
> nosearch option, so string.h was getting picked up from the standard system
> libraries instead of the version included with Metal C. I've pasted my
> optfile dataset I passed to the CPARM below for reference.
>
> //OPTIONS DD *
> SO
> LIST
> LONG
> NOXREF
> CSECT
> METAL
> LP64
> NOSEARCH
> search(/usr/include/metal/)
>
> Joe
>
> On Mon, Jan 11, 2021 at 12:39 PM Dennis Fitzpatrick <den...@dcfitz.com>
> wrote:
>
> > I'm a developer working with a client to develop Metal C functions for
> > their products. Up until recently I've defined __METAL_STATIC and
> > linked with SCCR3BND. I decided recently to play with the dynamic
> > library in LPALIB so I removed that #define. What I'm getting is
> > compile errors on the substitution macros from metal.h. That is the
> > first problem. I decided to try and circumvent the compile errors and
> > I think I found a bug in the memcmp library function. That is the
> > second problem. I'm really hoping someone will tell me I missed
> > something really obvious or missed some maintenance.
> >
> > I created a trivial sample program to demonstrate:
> >
> > /*
> > Sample for Metal C
> > */
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> >
> > int main(int argc, char** argv)
> > {
> > char* xarg = "abcd";
> > void *mem = malloc(64);
> > memset(mem, 0x0f, 64);
> > memcpy(mem, xarg, sizeof(xarg));
> > int mcmp = memcmp(mem, xarg, sizeof(xarg));
> > free(mem);
> > }
> > Of course, this compiles and runs just fine on Visual Studio where I
> > do my initial development. On z/OS XLC though I get errors like the
> following:
> >
> > 12 | memset(mem, 0x0f, 64);
> > | 12
> > 12 + ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 *
> > __ptr32)16) -> __cvtecvt -> __ecvtsdc -> __sdca\+ 12
> > ===========>
> >
> ....b...........a.................................................................................
> > *=ERROR===========> a - CCN3275 Unexpected text ')' encountered.
> > *=ERROR===========> b - CCN3045 Undeclared identifier ___MEMSET.
> > 12 +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
> > + 12
> > ===========>
> >
> .........................................c........................................................
> > *=ERROR===========> c - CCN3277 Syntax error: possible missing ')' or
> ','?
> >
> > The header file include list is exactly what I expect:
> >
> > 1 /usr/include/metal/stdio.h
> > 2 /usr/include/metal/metal.h
> > 3 /usr/include/metal/stddef.h
> > 4 /usr/include/metal/stdlib.h
> > 5 /usr/include/metal/builtins.h
> >
> > Looking through all of the layers in the metal.h header started me
> > looking for aspirin. I decided to push forward as an exercise by
> > defining my own structures to use the Metal C function vector. I
> > already had many of the standard z/OS structures mapped and added my
> > own mapping of sys_libv31_s with real function prototypes:
> >
> > struct sys_libv31_s
> > {
> > void (*_em_0)();
> > int (*_em_abs)(int,int); // 1
> > int (*_em_atoi)(char*); // 2
> > long (*_em_atol)(char*); // 3
> > long long (*_em_atoll)(char*); // 4
> > void* (*_em_calloc)(size_t); // 5
> >
> > And my own substitution macros to remove the metal.h definition and
> > put in my own EMCALL reference:
> >
> > #define EMCALL(_t, _n)
> > (##_t)(*(CVTPTR->CVTECVT->ECVTSDC->sdcalibv31->_em_##_n))
> > #define em_0 EMCALL(void, em_0)
> > #undef abs // 1
> > #define abs EMCALL(int, abs)
> > #undef atoi // 2
> > #define atoi EMCALL(int atoi)
> > #undef atol // 3
> > #define atol EMCALL(long, atol)
> > #undef atoll // 4
> > #define atoll EMCALL(long long, atoll) #undef calloc // 5 #define
> > calloc EMCALL(void *, calloc)
> >
> > I can't give you the whole thing as it is too much to extract from
> > client proprietary material. Hopefully, this is enough to get the gist.
> >
> > Now this is where I believe I found a bug in the memcmp function
> > returning an invalid result and also a potential S0C4. With getting
> > all of my code to compile I found things taking some weird code paths.
> > I tracked it down to a memcmp and setup the code in the sample above
> > to test it. I found the memcmp above returns an invalid result, 0x0f,
> > even though the memory is equal. I went into TEST and disassembled the
> code and got this:
> >
> >
> > 1F24CD78. STM R14,R3,12(R13)
> >
> > 1F24CD7C. LR R15,R13
> >
> > 1F24CD7E. L R13,8(,R13)
> >
> > 1F24CD82. ST R15,4(,R13)
> >
> > 1F24CD86. STMH R14,R3,80(R13)
> >
> > 1F24CD8C. L R14,0(,R1)
> >
> > 1F24CD90. L R2,4(,R1)
> >
> > 1F24CD94. ICM R0,15,8(R1)
> >
> > 1F24CD98. BRC 8,*+52
> >
> > 1F24CD9C. LR R1,R0
> >
> > 1F24CD9E. LLGC R15,0(,R14)
> >
> > 1F24CDA4. LLGC R3,0(,R2)
> >
> > 1F24CDAA. LA R14,1(,R14)
> >
> > 1F24CDAE. LA R2,1(,R2)
> >
> > 1F24CDB2. CR R15,R3
> >
> > 1F24CDB4. BRC 7,*+36
> >
> > 1F24CDB8. LLGC R15,0(,R14)
> >
> > 1F24CDBE. LLGC R3,0(,R2)
> >
> > 1F24CDC4. BRCT R1,*-26
> >
> > 1F24CDC8. BRC 15,*+16
> >
> > 1F24CDCC. LLGC R15,0(,R14)
> >
> > 1F24CDD2. LLGC R3,0(,R2)
> >
> > 1F24CDD8. SLR R15,R3
> >
> > 1F24CDDA. LMH R14,R3,80(R13)
> >
> > 1F24CDE0. L R13,4(,R13)
> >
> > 1F24CDE4. L R14,12(,R13)
> >
> > 1F24CDE8. LM R1,R3,24(R13)
> >
> > 1F24CDEC. BCR 15,R14
> >
> > The important thing is that the loop uses R14 & R2 as the character
> > pointers and R1 as the count. The loop at D9E loads the first bytes of
> > each memory area. Then it increments the pointers, does the compare,
> > and if NE branches to *+36 (DCC). It then reloads R15 & R3 but the
> > pointers have already been incremented. It calculates the difference
> > of the two bytes as the return value. This gets the two random bytes
> > after the memory area to compute the result which is an incorrout and
> > a possible S0C4. Similarly, it uses those same next bytes if the
> > result is BRC NE falls through giving random results and/or S0C4 if the
> strings are equal.
> >
> > I thought I was totally delusional at this point since how could any
> > code work if the memcmp library function was bad. Then I further found
> > that metal/builtin.h overrides the library call and causes a fair
> > number of these critical library functions to be inlined by the
> > compiler which of course generates good code. I also verified that
> > none of my old links with SCCR3BND pull in any of the library memory
> > functions (memcmp, memcpy, etc.) along with a bunch of other stdlib
> functions which builtin.h overrides.
> >
> > I'd be perfectly happy for someone to tell me I missed some obvious
> > compiler option or did something else really stupid.
> >
> >
> > Dennis C. Fitzpatrick
> > den...@dcfitz.com<mailto:den...@dcfitz.com>
> > H: 630.325.6184
> > W: 630.325.6137
> > M: 630.660.8040
> >
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
