From: Luis Machado <lgustavo@codesourcery.com>
To: Pedro Alves <palves@redhat.com>, "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: Tue, 12 Jan 2016 13:25:00 -0000 [thread overview]
Message-ID: <5694FEB8.10406@codesourcery.com> (raw)
In-Reply-To: <5694F5BC.3050904@redhat.com>
On 01/12/2016 10:46 AM, Pedro Alves wrote:
> On 01/11/2016 03:47 PM, Luis Machado wrote:
>> 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;
>
> This callback is registered for bfd_arch_mips:
>
> gdbarch_register (bfd_arch_mips, mips_gdbarch_init, mips_dump_tdep);
>
> Does bfd think this a bfd_arch_mips binary? How so?
In the second time we call gdbarch_info_fill, when opening the core file
alone, we have this:
p *info
$8 = {bfd_arch_info = 0x0, byte_order = BFD_ENDIAN_UNKNOWN,
byte_order_for_code = BFD_ENDIAN_UNKNOWN, abfd = 0xe1ce80, tdep_info =
0x0, osabi = GDB_OSABI_UNINITIALIZED, target_desc = 0x0}
p *info->abfd->arch_info
$10 = {bits_per_word = 32, bits_per_address = 32, bits_per_byte = 8,
arch = bfd_arch_unknown, mach = 0, arch_name = 0x9b799f "unknown",
printable_name = 0x9b799f "unknown", section_align_power = 2,
the_default = 1, compatible = 0x78a592 <bfd_default_compatible>,
scan = 0x78a60a <bfd_default_scan>, fill = 0x78acc6
<bfd_arch_default_fill>, next = 0x0}
p *default_bfd_arch
$12 = {bits_per_word = 32, bits_per_address = 32, bits_per_byte = 8,
arch = bfd_arch_mips, mach = 0, arch_name = 0x9d98e0 "mips",
printable_name = 0x9d98e0 "mips", section_align_power = 3, the_default =
1, compatible = 0x832b40 <mips_compatible>,
scan = 0x78a60a <bfd_default_scan>, fill = 0x78acc6
<bfd_arch_default_fill>, next = 0x9d9b00 <arch_info_struct>}
The data above leads gdbarch_info_fill to assign default_bfd_arch to
info->bfd_arch_info here:
/* From the default. */
if (info->bfd_arch_info == NULL)
info->bfd_arch_info = default_bfd_arch;
So the core file essentially turns into a mips-compatible core file.
This also happens with a powerpc-targeted gdb and likely any other
architecture.
For powerpc we get lucky and end up "passing" this test because it has
no fatal failing conditions. It ends up displaying frame -1 for me, like so:
PC not available^M
#-1 <unavailable> in ?? ()
next prev parent reply other threads:[~2016-01-12 13:25 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
2016-01-12 12:46 ` Pedro Alves
2016-01-12 13:25 ` Luis Machado [this message]
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=5694FEB8.10406@codesourcery.com \
--to=lgustavo@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=macro@imgtec.com \
--cc=palves@redhat.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