Thank you :)

>In order to trigger corruption, you need to interrupt a function that uses
>the red zone.  It's up the compiler whether or not (and how) it uses that zone,
>so this is not something you can reliably trigger.

I realised this. I was not able to control this. For example if I have a function a () called from main and I am in a  () and then I use the call feature of GDB to call b (), GDB is safely creating a frame, whether b () needs an integer array of 1, 100 or 1000 and then manages to reproduce the volatile register contents of a () as it was before the call b ().. So yeah.. But a nice concept to learn. Thanks again.

From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Date: Friday, 25 August 2023 at 9:20 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>, Aditya Kamath1 <Aditya.Kamath1@ibm.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] Fix 64 bit red zone frame size in AIX
Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>So, we should leave 18*8 + 18*8 = 288 bytes in 64-bit mode.. This patch does this..

I think this is right - GCC assumes a 288 byte red zone on 64-bit AIX as well.

I've committed the patch now.

>Having said that when I tried to see if I can corrupt something while the red zone
>frame size was 0 in 64-bit mode I was not successful.

In order to trigger corruption, you need to interrupt a function that uses
the red zone.  It's up the compiler whether or not (and how) it uses that zone,
so this is not something you can reliably trigger.

If you want to experiment, I'd suggest using a leaf function that requires
some (but not too much) space on the stack.

Bye,
Ulrich