From: Luis Machado <lgustavo@codesourcery.com>
To: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: <gdb-patches@sourceware.org>, <jan.kratochvil@redhat.com>
Subject: Re: [PATCH] Handle loading improper core files gracefully in the mips backend.
Date: Mon, 11 Jan 2016 15:47:00 -0000 [thread overview]
Message-ID: <5693CE90.1060709@codesourcery.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1601090245560.5958@tp.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On 01/09/2016 01:02 AM, Maciej W. Rozycki wrote:
> On Fri, 8 Jan 2016, Luis Machado wrote:
>
>> Maciej, do you have more input on additional incompatibilities that we need
>> to check for?
>
> Why do we get this far in the first place where e_machine != EM_MIPS? I
> think rather than adding additional checks here (unless they're needed for
> a valid MIPS ELF binary; but that would be a separate problem to fix) we
> should reject such a core file outright.
I thought about that, but no targets other than v850 use e_machine
information during arch initialization, which is strange. It seems we
just don't enforce compatibility, at least when loading core files.
Does the attached patch match what you have in mind? I also adjusted the
testcase to expect core file rejection and also got rid of duplicated
test strings.
Now a mips-targeted GDB says the following when trying to load a x86
core file:
gdb.arch/i386-biarch-core.core": no core file handler recognizes format
[-- Attachment #2: 0001-Handle-loading-improper-core-files-gracefully-in-the.patch --]
[-- Type: text/x-patch, Size: 2699 bytes --]
gdb/ChangeLog:
2016-01-11 Luis Machado <lgustavo@codesourcery.com>
bz 18964
* mips-tdep.c (mips_gdbarch_init): Sanity check ELF e_machine
field and bail out if it is not MIPS-compatible.
gdb/testsuite/ChangeLog:
2016-01-11 Luis Machado <lgustavo@codesourcery.com>
bz 18964
* gdb.arch/i376-biarch-core.exp: Handle the core file not being
recognized.
Use variables for repeating test names.
---
gdb/mips-tdep.c | 6 ++++++
gdb/testsuite/gdb.arch/i386-biarch-core.exp | 18 +++++++++++++++---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c
index ca17864..cdfd80e 100644
--- a/gdb/mips-tdep.c
+++ b/gdb/mips-tdep.c
@@ -8208,6 +8208,12 @@ mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
int dspacc;
int dspctl;
+ /* Sanity check the e_machine field. */
+ if (info.abfd
+ && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour
+ && elf_elfheader (info.abfd)->e_machine != EM_MIPS)
+ return NULL;
+
/* Fill in the OS dependent register numbers and names. */
if (info.osabi == GDB_OSABI_IRIX)
{
diff --git a/gdb/testsuite/gdb.arch/i386-biarch-core.exp b/gdb/testsuite/gdb.arch/i386-biarch-core.exp
index 607b947..a4c0541 100644
--- a/gdb/testsuite/gdb.arch/i386-biarch-core.exp
+++ b/gdb/testsuite/gdb.arch/i386-biarch-core.exp
@@ -28,13 +28,14 @@ gdb_start
gdb_reinitialize_dir $srcdir/$subdir
set test "complete set gnutarget"
+set text_test ".text is readable"
gdb_test_multiple "complete set gnutarget " $test {
-re "set gnutarget elf64-little\r\n(.*\r\n)?$gdb_prompt $" {
pass $test
}
-re "\r\n$gdb_prompt $" {
pass $test
- untested ".text is readable"
+ untested $text_test
return
}
}
@@ -62,8 +63,19 @@ if {$corestat(size) != 102400} {
# objcopy as it corrupts the core file beyond all recognition.
# The output therefore does not matter much, just we should not get GDB
# internal error.
-gdb_test "core-file ${corefile}" ".*" "core-file"
+set test "core-file"
+gdb_test_multiple "core-file ${corefile}" $test {
+ -re ".* no core file handler recognizes format\r\n$gdb_prompt $" {
+ # Make sure we handle cases where the core file isn't even properly
+ # loaded due to architecture incompatibilities.
+ untested $text_test
+ return
+ }
+ -re "\r\n$gdb_prompt $" {
+ pass $test
+ }
+}
# Test if at least the core file segments memory has been loaded.
# https://bugzilla.redhat.com/show_bug.cgi?id=457187
-gdb_test "x/bx $address" "\r\n\[ \t\]*$address:\[ \t\]*0xf4\[ \t\]*" ".text is readable"
+gdb_test "x/bx $address" "\r\n\[ \t\]*$address:\[ \t\]*0xf4\[ \t\]*" $text_test
--
1.9.1
next prev parent reply other threads:[~2016-01-11 15:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-08 18:32 Luis Machado
2016-01-09 3:02 ` Maciej W. Rozycki
2016-01-11 15:47 ` Luis Machado [this message]
2016-01-12 12:46 ` Pedro Alves
2016-01-12 13:25 ` Luis Machado
2016-01-12 14:10 ` Pedro Alves
2016-01-12 15:43 ` Luis Machado
2016-01-12 16:00 ` Pedro Alves
2016-01-12 18:30 ` Maciej W. Rozycki
2016-01-12 19:08 ` Pedro Alves
2016-02-02 12:58 ` Luis Machado
2016-02-02 14:19 ` Pedro Alves
2016-02-02 14:22 ` Pedro Alves
2016-02-04 21:01 ` Maciej W. Rozycki
2016-02-05 11:29 ` Luis Machado
2016-02-05 14:10 ` Maciej W. Rozycki
2017-01-09 19:57 ` Luis Machado
2017-01-19 16:56 ` Pedro Alves
2017-01-19 17:05 ` Luis Machado
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=5693CE90.1060709@codesourcery.com \
--to=lgustavo@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=macro@imgtec.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