From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752038AbdC0TVt (ORCPT ); Mon, 27 Mar 2017 15:21:49 -0400 Received: from b.ns.miles-group.at ([95.130.255.144]:44724 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751677AbdC0TU5 (ORCPT ); Mon, 27 Mar 2017 15:20:57 -0400 Subject: Re: Getting the way a SIGSEGV append when catching a SIGSEGV from within To: none References: Cc: Linux Kernel , linux-x86_64@vger.kernel.org From: Richard Weinberger Message-ID: <2de78272-1cd7-ca1a-c3a3-950de331b727@nod.at> Date: Mon, 27 Mar 2017 21:20:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 27.03.2017 um 20:55 schrieb none: > Le 2017-03-27 17:30, Richard Weinberger a écrit : >> On Mon, Mar 27, 2017 at 4:45 PM, none wrote: >>> Hello, >>> >>> There’s three way to perform an invalid memory access : >>> >>> The attempt to execute/jump at an invalid address. >>> The attempt to read at an invalid address. >>> The attempt to write at an invalid address. >>> >>> Determining the execute case with rt_sigaction is easy : the last value of >>> eip match the value of the address which caused the segfault. >>> >>> But how to know if the SIGSEGV occurred by a read or by a write attempt ? In >>> the same time shouldn’t that information belong in the mmu ? >> >> Did you look at the machine specific context of SIGSEGV? >> It will give you access to the error code and the trap number. > > Sorry but so, in the case of x86_64, which is the struct member I need to look at ? ucontext_t *c = context; // context is the 3rd parameter to your SIGSEGV handler when SA_SIGINFO is set mcontext_t m = c->uc_mcontext; m.gregs[REG_ERR] and m.gregs[REG_TRAPNO] are what you want. HTH, //richard