Well, those will catch some refreshabilty violations, but there are other types of reenterability violations than unserialized self modifying code, and the assembler can't catch those.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Jonathan Scott <[email protected]> Sent: Tuesday, April 23, 2019 8:08 AM To: [email protected] Subject: Re: Fwd: Sysadata symbol and literal cross reference record type Ref: Your note of Mon, 22 Apr 2019 11:06:34 -0400 One way of detecting and preventing the use of self-modifying code is to use RSECT instead of CSECT for any section which is intended to be read-only, in which case HLASM will flag a reentrancy violation if it detects an attempt to store into that section. Another is to use the RENT option, which will enable that check for all control sections. However, as code may deliberately use CSECT to map initialised work areas, this may not provide sufficiently fine-grained control. Joseph Reichman writes: > Hi > > For programs that have self modifying code > Adata record type 44 can prove to be a valuable tool in identifying them > as the reference flag has a 'M' > > However I wonder if there is a easy way to identify code that is being > modified by location counter I.E MVI *+5,X'00' and the following > instruction is for example B AROUND > > Thanks Jonathan Scott, HLASM IBM Hursley, UK
