Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alan Hayward via Gdb-patches <gdb-patches@sourceware.org>
To: Mike Frysinger <vapier@gentoo.org>
Cc: Fredrik Hederstierna <fredrik.hederstierna@verisure.com>,
	Simon Marchi <simark@simark.ca>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Paul Mathieu <paulmathieu@google.com>
Subject: Re: [PATCH] sim: arm: add support for handling core dumps
Date: Thu, 24 Jun 2021 13:01:00 +0000	[thread overview]
Message-ID: <36F6111C-FF52-4002-8B5F-5758F09F1859@arm.com> (raw)
In-Reply-To: <YNFW+dgO3A4BcorP@vapier>



> On 22 Jun 2021, at 04:20, Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org> wrote:
> 
> On 21 Jun 2021 06:30, Fredrik Hederstierna via Gdb-patches wrote:
>> The ARM simulator does not support all registers, and also crash in case of entering zero length when fetching registers.
>> This patch allow gcore to also work in ARM simulator, though by default it seems to dump full memory space 4GB, so core files get very large, though seems to work ok anyhow.
> 
> dumping the entire address space doesn't sound unreasonable for bare metal env.
> you have an ELF which will tell you the memory regions it occupies directly,
> but there's no API i'm aware of to communicate things like stack & heap.
> 
> that said, the arm sim has some non-ideal behavior.  it allocates 2MiB by
> default, but after that, access to anywhere in the 4GiB address space will
> automatically allocate a page if one hasn't yet.  if someone gets around to
> gutting arm's custom memory implementation and switching it to the common
> sim memory core, this would get fixed in the process ...
> 
>> --- a/gdb/arm-tdep.c
>> +++ b/gdb/arm-tdep.c
>> @@ -4246,6 +4246,10 @@ arm_register_sim_regno (struct gdbarch *gdbarch, int regnum)
>>   if (regnum >= ARM_WCGR0_REGNUM && regnum <= ARM_WCGR7_REGNUM)
>>     return regnum - ARM_WCGR0_REGNUM + SIM_ARM_IWMMXT_COP1R8_REGNUM;
>> 
>> +  /* The current GDB ARM simulator does not support D0-D31 nor FPSCR.  */
>> +  if (regnum >= ARM_D0_REGNUM && regnum <= ARM_FPSCR_REGNUM)
>> +    return -1;
>> +
>>   if (reg < NUM_GREGS)
>>     return SIM_ARM_R0_REGNUM + reg;
>>   reg -= NUM_GREGS;
> 
> shouldn't this check be at the end of arm_register_sim_regno instead of
> calling internal error ?

I’m not familiar with the sim, so Im going to assume the comment statement is correct.

With the added code, it means the "if (reg < NUM_FREGS)” and "if (reg < NUM_SREGS)” statements can never be hit.
So, it’s probably worth removing those.

Agree with Mike’s comment - the internal_error at the end of the function needs dropping too. The caller handles the bad value.


>> --- a/sim/arm/wrapper.c
>> +++ b/sim/arm/wrapper.c
>> @@ -526,6 +526,10 @@ arm_reg_fetch (SIM_CPU *cpu, int rn, unsigned char *memory, int length)
>> 
>>   init ();
>> 
>> +  /* Check that memory and length are valid before fetching the register.  */
>> +  if ((memory == NULL) || (length == 0))
>> +    return 0;
> 
> why is the caller passing NULL to the sim ?
> -mike


  reply	other threads:[~2021-06-24 13:01 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17  0:02 [PATCH] gdb: add support for handling core dumps on arm-none-eabi Fredrik Hederstierna via Gdb-patches
2020-10-19  2:08 ` Simon Marchi
2020-10-19 13:13   ` Luis Machado via Gdb-patches
2020-10-19 13:15   ` Alan Hayward via Gdb-patches
2020-10-19 15:25   ` Paul Mathieu via Gdb-patches
2020-10-20 11:41     ` Fredrik Hederstierna via Gdb-patches
2020-10-20 12:39       ` Simon Marchi
2020-10-20 14:00         ` Fredrik Hederstierna via Gdb-patches
2020-10-20 15:04           ` Simon Marchi
2020-10-20 22:05             ` Fredrik Hederstierna via Gdb-patches
2020-10-20 23:06               ` Simon Marchi
2020-10-22  0:52                 ` Fredrik Hederstierna via Gdb-patches
2020-10-22  1:24                   ` Simon Marchi
2020-10-22  1:49                   ` Simon Marchi
2020-10-22 22:32                     ` Fredrik Hederstierna via Gdb-patches
2020-10-23  0:37                       ` Simon Marchi
2020-10-25 21:06                         ` Fredrik Hederstierna via Gdb-patches
2020-10-26 11:24                           ` Luis Machado via Gdb-patches
2020-10-26 15:49                             ` Fredrik Hederstierna via Gdb-patches
2020-10-27 16:53                               ` Paul Mathieu via Gdb-patches
2021-01-14 12:36                                 ` Fredrik Hederstierna via Gdb-patches
2021-01-14 12:50                                   ` Luis Machado via Gdb-patches
2021-01-18 11:09                                     ` Andrew Burgess
2021-01-18 14:01                                       ` Luis Machado via Gdb-patches
2021-06-21  6:30                                         ` [PATCH] sim: arm: add support for handling core dumps Fredrik Hederstierna via Gdb-patches
2021-06-22  3:20                                           ` Mike Frysinger via Gdb-patches
2021-06-24 13:01                                             ` Alan Hayward via Gdb-patches [this message]
2021-06-29  9:11                                               ` Fredrik Hederstierna via Gdb-patches
2021-01-18 11:01                                   ` [PATCH] gdb: add support for handling core dumps on arm-none-eabi Andrew Burgess
2021-06-22  2:16                           ` Mike Frysinger via Gdb-patches
2020-10-20 19:34       ` [PATCH] gdb: Support corefiles for arm-none-eabi Fredrik Hederstierna
2020-10-20 21:49       ` Fredrik Hederstierna
2020-10-20 21:58       ` [PATCH v2] Support for corefiles for arm-none-eabi target Fredrik Hederstierna
2020-10-21  2:51         ` Simon Marchi
2020-10-21 14:38         ` Luis Machado via Gdb-patches
2020-10-22  0:44       ` [PATCH v3][PR gdb/14383]: gdb: corefile support " Fredrik Hederstierna
2020-10-22  0:44         ` [PATCH v3][PR gdb/14383]: Support for corefiles " Fredrik Hederstierna
2020-10-25 20:46       ` [PATCH] " Fredrik Hederstierna
2020-10-25 20:50       ` [PATCH v4][PR gdb/14383] " Fredrik Hederstierna

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=36F6111C-FF52-4002-8B5F-5758F09F1859@arm.com \
    --to=gdb-patches@sourceware.org \
    --cc=Alan.Hayward@arm.com \
    --cc=fredrik.hederstierna@verisure.com \
    --cc=paulmathieu@google.com \
    --cc=simark@simark.ca \
    --cc=vapier@gentoo.org \
    /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