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
