Re: Metal C and generated Assembler

2020-07-06 Thread Steve Smith
My guess is that something in your inserted prologue/epilogue code contains
a forward-reference that causes HLASM to suspend the location counter in
pre-assembly.

The message (ASMA032E) is a prime example of the anti-pattern of issuing an
error message that makes you guess which of the listed possibilities is the
problem.  I'm guessing it's "unresolved symbol" due to the above.

sas


On Mon, Jul 6, 2020 at 12:51 PM Scott Fagen 
wrote:

> I have a Metal C program where I am trying to add some static data via an
> __asm(“…” : DS(staticdata)) statement, but I am having some issues with the
> generated assembler code.
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Metal C and generated Assembler

2020-07-06 Thread Scott Fagen
On Mon, 6 Jul 2020 13:59:30 -0400, Steve Smith  wrote:

>My guess is that something in your inserted prologue/epilogue code contains
>a forward-reference that causes HLASM to suspend the location counter in
>pre-assembly.
>
Steve - any idea of what I should be looking for.  It's not clear to me how you 
came to this conclusion:  

1) The $STATIC area does seem to be rightfully placed in the module:  here is 
the previous CKKTESTR CSECT from the assembler listing:

0006F80 00948  1760 CKKTESTR CSECT ,
 00 
0006F8 1761 @@CONST@AREA@@ DS 0D
 00 
0006F8 C595A385998584401762  DC
XL16'C595A38599858440A38885E2A4827A00'00 
000708 C595A385998584401763  DC
XL16'C595A38599858440A38885E2A4827A40'00 
000718 D9858396A58599A81764  DC
XL16'D9858396A58599A8C5A789A300C9C595'00 
000728 A38599858440A3881765  DC
XL16'A38599858440A38885E2A4827A40D985'00 
000738 A399A800C595A3851766  DC
XL16'A399A800C595A38599858440D4818995'00 
000748 4D5D40D48189957A1767  DC
XL16'4D5D40D48189957A00C9C595A3859985'00 
000758 8440D48189954D5D1768  DC
XL16'8440D48189954D5D40D9858396A58599'00 
000768 A8C5A789A37A00C91769  DC
XL16'A8C5A789A37A00C9C595A38599858440'00 
000778 D48189954D5D40D91770  DC
XL14'D48189954D5D40D985A399A87A00'00 
 5650ZOS V2.2 z/OS XL C
"SSAF.METALC.C(CKKTESTR)"   Page   36
  Active Usings: None   

  Loc  Object CodeAddr1 Addr2  Stmt   Source Statement  
HLASM R6.0  2020/07/06 14.28
0007860 00948  1772 CKKTESTR CSECT ,
 00 
000788 1773 $STATIC  DS0D   
 00 
000788 1774  DC(336)X'00'   
 00 
0008D8008D8 007C8  1775  ORG   $STATIC+64   
 00 

And @@LAB@xL is "8" in both the working and non-working versions of the 
assembler code...based on the length of the DC CL4 followed by the DS 0D...

Scott Fagen
21st Century Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Metal C and generated Assembler

2020-07-07 Thread David Crayford

Hi Scott,

It would be useful to see a more complete C snippet. IIRC, I've seen 
this before where the __asm("":DS()) was not declared outside of the 
main function.


On 2020-07-07 12:51 AM, Scott Fagen wrote:

I have a Metal C program where I am trying to add some static data via an 
__asm(“…” : DS(staticdata)) statement, but I am having some issues with the 
generated assembler code.

When I use my own prolog and epilog code, I get:

0007E60 009A8  1997 CKKTESTR CSECT ,
 00
0007E8 1998 $STATIC  DS0D   
 00
0007E8 1999  DC(336)X'00'   
 00
00093800938 00828  2000  ORG   $STATIC+64   
 00
000828 000100302001  DCXL8'00010030'
 00
00083000830 00830  2002  ORG   $STATIC+72   
 00
000830 F2F1C3E2D9C5C3D72003  DCXL8'F2F1C3E2D9C5C3D7'
 00
00083800838 007F8  2004  ORG   $STATIC+16   
 00
0007F8 C5E2C5412005  DC
XL16'C5E2C54100010090'00
000808 009000202006  DC
XL16'00900020C5E2C3C10001'00
000818 000100802007  DC
XL16'0001008000800014'00
00082800828 007E8  2008  ORG   $STATIC  
 00
0007E8 00012009  DCXL4'0001'
 00
0007EC007EC 007EC  2010  ORG   $STATIC+4
 00
0007EC F2F1C3E22011  DC
XL12'F2F1C3E27BAD'00
0007F8007F8 00938  2012  ORG   ,
 00
2013  LCLC  &DSMAC  
  00
2014  LCLA  &DSSIZE 
  00
2015  LCLA  &MSIZE  
  00
00093800938 00838  2016  ORG   $STATIC+80   
 00
   008382017 @@LAB@3  EQU   *   
  00
000838 2018  DS0D  
Start copyright text on a 00
   008382019 TheESET  EQU   *   
Address of the ESES   00
000838 F2F1C3E22020  DCCL4'21CSESES'   
Control block eyecatcher  00
2021 *.DC.F'1'.Control block version
  00
2022 *.DC.CL8'CKKTESTR'.CSECT name  
  00
2023 *.DC.CL8'HTES120'.FMID 
  00
2024 *.DC.CL8'XXRMIDXX'.RMID
  00
2025 *.DC.CL8'21CS-TS1'.PID 
  00
2026 *.DC.CL19'2020-07-04 02:25:21.816513'  
  00
2027 *.DC.CL5''.Pad with blanks 
  00
2028 *.DC.C'Copyright '.Copyright text  
  00
2029 *.DC.C'(C) Teracloud S.A. '.Copyright 
Teracloud S.A. 00
2030 *.DC.C'1991,2001'.Insert the year(s)   
  00
000840 2031 EndCKKModId DS 0D  
End of ESES and copyright 00
   82032 @@LAB@3L EQU   *-@@LAB@3   
  00
2033 &DSMAC   SETC  '@@LAB@3'   
  00
2034 &DSSIZE  SETA  256

Re: Metal C and generated Assembler

2020-07-07 Thread Scott Fagen
On Mon, 6 Jul 2020 14:55:39 -0500, Scott Fagen  wrote:

With a great deal of online help from Steve Smith and Alex Brodsky, they 
(independently) discovered that "above" the displayed code (generated within my 
prolog), I had a DS statement that had a variable duplication factor that 
relied on a value that was "below" (declared by one of the macros in an 
insert_asm statement).  This keeps the assembler from knowing at the time of 
the failing SETA statement what the location counter is and it fails, even 
though the results of the statement only needs the relative offsets.

For clarity, the point of the code being generated by the compiler is to ensure 
that the data generated within the __asm(...:DS...) statement is less than or 
equal to the length specified (defaults to 255).

From a user perspective, the error messages are inscrutable.

** ASMA032E Relocatable value or unresolved symbol found when absolute value 
required - OPENC/@@LAB@3L 
** ASMA435I Record 944 in SSAF.METALC.C.ASM(CKKTESTR) on volume: TSO001

I'm guessing that OPENC means "open code," @@LAB@3L is where the failure is 
occuring, but looking at the output after the assembler is finished doesn't 
make it obvious that @@LAB@3L was somehow defective when the SETA was being 
processed.

Scott Fagen
21st Century Software
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Metal C and generated Assembler

2020-07-21 Thread Linda Chui
hi Scott,

Thank you for opening a case for this in our official support channel. We will 
handle from there.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN