Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 19 May 2020 16:02:04 +0100
From:   Russell King - ARM Linux admin <linux@armlinux.org.uk>
To:     Andrew Jeffery <andrew@aj.id.au>
Cc:     linux-arm-kernel@lists.infradead.org, oleg@redhat.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: Implement functions for HAVE_FUNCTION_ARG_ACCESS_API
Message-ID: <20200519150204.GG1551@shell.armlinux.org.uk>
References: <20200519143132.603579-1-andrew@aj.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200519143132.603579-1-andrew@aj.id.au>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, May 20, 2020 at 12:01:32AM +0930, Andrew Jeffery wrote:
> This allows extraction of kernel function arguments via kprobes on ARM.
> Based on the arm64 implementation and adapted for the 32-bit AAPCS.
> 
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> The description for HAVE_FUNCTION_ARG_ACCESS_API was pretty vague on what was
> required. I've implemented enough to enable argument extraction for kprobes; is
> there anything else needed to satisfy HAVE_FUNCTION_ARG_ACCESS_API?

What about 64-bit arguments?  How do they get handled?

regs_get_kernel_argument() talks about 'n' being the argument number,
and maps this directly to a register.  If a function argument
prototype is:

	(something *foo, long long bar, int baz)

The foo is in r0, bar is in r2/r3 on EABI, and baz is on the stack.

n=0 will return foo.  n=1 will be undefined.  n=2 will return part of
bar, and n=3 will return the other half.  Is this what is expected?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up