From: Yao Qi <qiyaoltc@gmail.com>
To: Steve Ellcey <sellcey@caviumnetworks.com>
Cc: binutils <binutils@sourceware.org>,
gdb-patches <gdb-patches@sourceware.org>,
Yury Norov <ynorov@caviumnetworks.com>,
schwab@suse.de, "Pinski, Andrew" <Andrew.Pinski@cavium.com>
Subject: Re: [PATCH] Patch 2 of 2 for aarch64 ILP32 support in gdb
Date: Sun, 29 Jan 2017 22:41:00 -0000 [thread overview]
Message-ID: <20170129224045.ekflcodtmfs4hv54@localhost> (raw)
In-Reply-To: <1485555939.2509.5.camel@caviumnetworks.com>
On 17-01-27 14:25:39, Steve Ellcey wrote:
> That patch seems reasonable and it fixed some test failures I had
> in the glibc testsuite but it is breaking gdb.????If I undo this
> patch by making this change to bfd/cpu-aarch64.c:
>
> ??static const bfd_arch_info_type bfd_aarch64_arch_ilp32 =
> -????N (bfd_mach_aarch64_ilp32, "aarch64:ilp32", 32, FALSE, NULL);
> +????N (bfd_mach_aarch64_ilp32, "aarch64:ilp32", 64, FALSE, NULL);
>
This changes the word size and address size, which is used to determine
the inferior is arm or aarch64 by checking "bits_per_word == 32" in
multi-arch debugging. You can find some instances of such check in
aarch64-linux-nat.c. If the bits_per_word is 32 in ILP32, GDB thinks
the inferior is an ARM one, rather than an AArch64 ILP32 one. which is
wrong. We need to tweak the condition above to correctly identify the
ARM inferior.
> Then gdb starts working again and I can debug 32 bit programs.
>
> I am not sure how this change to the ILP32 aarch64 bfd description
> is affecting gdb and why this change would break things.????Do you
> know why this change messes up gdb?
>
D0 you compare the ILP32 gdb test result with normal aarch64 one?
> +
> /* Return the pseudo register name corresponding to register regnum. */
>
> static const char *
> @@ -2851,6 +2867,10 @@ aarch64_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> const struct tdesc_feature *feature;
> int num_regs = 0;
> int num_pseudo_regs = 0;
> + bool ilp32 = FALSE;
> +
s/FALSE/false/
> + if (info.bfd_arch_info->mach == bfd_mach_aarch64_ilp32)
> + ilp32 = TRUE;
s/TRUE/true/
--
Yao
next prev parent reply other threads:[~2017-01-29 22:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 0:20 Steve Ellcey
2017-01-26 14:14 ` Yao Qi
2017-01-27 22:26 ` Steve Ellcey
2017-01-29 22:41 ` Yao Qi [this message]
2017-01-31 23:16 ` Steve Ellcey
2017-02-01 22:20 ` Yao Qi
2017-02-01 22:23 ` Yao Qi
2017-02-02 0:27 ` Steve Ellcey
2017-02-02 0:40 ` Steve Ellcey
2017-02-02 9:52 ` Yao Qi
2017-02-02 22:04 ` Steve Ellcey
2017-02-03 9:17 ` 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=20170129224045.ekflcodtmfs4hv54@localhost \
--to=qiyaoltc@gmail.com \
--cc=Andrew.Pinski@cavium.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=schwab@suse.de \
--cc=sellcey@caviumnetworks.com \
--cc=ynorov@caviumnetworks.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