All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 2/2] tests/tcg: port SYS_HEAPINFO to a system test
Date: Wed, 9 Feb 2022 19:02:48 +0000	[thread overview]
Message-ID: <CAFEAcA87H4OibHzuz=EycSEFo=jAzMoCxij8KDdoFHjrp54vjQ@mail.gmail.com> (raw)
In-Reply-To: <87k0e3ewjg.fsf@linaro.org>

On Wed, 9 Feb 2022 at 18:15, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Wed, 9 Feb 2022 at 17:26, Alex Bennée <alex.bennee@linaro.org> wrote:
> >> It should be in this case because boot.S sets stack to be inside out
> >> data segment.
> >
> > So what you mean is
> >
> >  /*
> >   * boot.S put our stack somewhere inside the text segment of the
> >   * ELF file, and we know that SYS_HEAPINFO won't pick a range
> >   * that overlaps with part of a loaded ELF file. So the info
> >   * struct (on the stack) should not be inside the reported heap.
> >   */
> >
> > ?
>
> Well the data segment (but not the bss).

Ah, yes, I missed the ".data" when I was scanning the file.
(For a system binary it doesn't matter, because our ELF loader
doesn't care whether the segment is marked read-only or
read-write, it just loads it into RAM.)

> So as long as the ELF loader
> includes that in the calculation (which it should I think) then we are
> ok.

Should be OK -- the ELF loader creates a rom blob for every
segment in the file, and then the SYS_HEAPINFO implementation
will avoid them all.

-- PMM


      reply	other threads:[~2022-02-09 19:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 13:47 [PATCH v4 0/2] semihosting/next (SYS_HEAPINFO) Alex Bennée
2021-06-23 13:47 ` [PATCH v4 1/2] semihosting/arm-compat: replace heuristic for softmmu SYS_HEAPINFO Alex Bennée
2021-06-28 19:48   ` Peter Maydell
2022-02-09 16:29     ` Alex Bennée
2022-02-09 17:13       ` Peter Maydell
2021-06-23 13:47 ` [PATCH v4 2/2] tests/tcg: port SYS_HEAPINFO to a system test Alex Bennée
2021-06-28 20:01   ` Peter Maydell
2022-02-09 17:25     ` Alex Bennée
2022-02-09 17:44       ` Peter Maydell
2022-02-09 18:14         ` Alex Bennée
2022-02-09 19:02           ` Peter Maydell [this message]

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='CAFEAcA87H4OibHzuz=EycSEFo=jAzMoCxij8KDdoFHjrp54vjQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.