From: "Tedeschi, Walfred" <walfred.tedeschi@intel.com>
To: "Joel Brobecker (brobecker@adacore.com)" <brobecker@adacore.com>,
"Yao Qi (qiyaoltc@gmail.com)" <qiyaoltc@gmail.com>,
"Pedro Alves (palves@redhat.com)" <palves@redhat.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: New siginfo type in kernel how to make gdb back compatible.
Date: Fri, 17 Jul 2015 12:35:00 -0000 [thread overview]
Message-ID: <AC542571535E904D8E8ADAE745D60B194444ED12@IRSMSX104.ger.corp.intel.com> (raw)
Hello All,
With Memory protection extensions the siginfo type has got new fields and new interpretation for a segmentation fault.
A segmentation fault can be now a signal for a bound violation. This is represented by segmentation fault with sigcode 3.
The new siginfo structure can be found here:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/uapi/asm-generic/siginfo.h?id=refs/tags/v4.1.2
to be more elucidative the sigfault part of the sifields is now:
struct {
void __user *_addr; /* faulting insn/memory ref. */
#ifdef __ARCH_SI_TRAPNO
int _trapno; /* TRAP # which caused the signal */
#endif
short _addr_lsb; /* LSB of the reported address */
struct {
void __user *_lower; /* <<<<<---- new field */
void __user *_upper; /* <<<<<---- new field */
} _addr_bnd;
} _sigfault;
Glibc will have also to follow those changes.
GDB should be nevertheless back compatible, i.e. capable of displaying the siginfo for applications running on systems having older glibc.
In case this is desirable and I do think it is.
How should we think about resolving that in terms of the siginfo type redefined inside of GDB?
I first thought about using the __libc_version, but not sure if this is a brilliant idea.
Thanks a lot and best regards,
-Fred
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next reply other threads:[~2015-07-17 12:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 12:35 Tedeschi, Walfred [this message]
2015-07-17 15:41 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AC542571535E904D8E8ADAE745D60B194444ED12@IRSMSX104.ger.corp.intel.com \
--to=walfred.tedeschi@intel.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=palves@redhat.com \
--cc=qiyaoltc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox