I pretty much agree, except there is not any "extreme" overhead in doing so. And there is not any issue with catching instructions executed out of the data section via an EX instruction.
As a counter example, our production systems run with embedded debugger code, which does *not* affect execution speed at all. -Paul -----Original Message----- From: Gibney, Dave [mailto:[email protected]] Sent: Wednesday, July 14, 2010 02:16 PM To: [email protected] Subject: Re: z Linux assembler relative or friend or foe? The original assertion was that under normal zLinux processing, certainproblem state instructions (specifically EPSW) were not allowed to beexecuted.As there seems to be no (without incurring the massive overhead ofeffectively interpreting/single stepping the execution (and even thatseems bypassable using the example give via the EX instruction)) nativeway to do this with zArch, this long discussion is occurring.The conclusion still must be that under routine execution of zLinux userprograms, all problem state instructions execute according to PoP. Yes,incurring the overhead of various tracing or screening during the loadof the executable code (or even scanning loaded code for dynamicallycreated instructions) could, at the expense of extreme overhead, preventEPSW or MVC or whatever, but IMO, no production system would bepractical with such a burden of overhead for such small, if any gain.Dave GibneyInformation Technology ServicesWashington State University
