From: Peter Maydell <peter.maydell@linaro.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>,
Andrew Strauss <astrauss11@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2] semihosting/arm-compat: remove heuristic softmmu SYS_HEAPINFO
Date: Thu, 10 Jun 2021 15:25:44 +0100 [thread overview]
Message-ID: <CAFEAcA9NYv1GdA+2P_7hbqgBwRTv6JFgfp1mS_PzURY-aafkeA@mail.gmail.com> (raw)
In-Reply-To: <87im2liz4x.fsf@linaro.org>
On Thu, 10 Jun 2021 at 15:16, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
> > I'm told that the Arm C compiler C library always assumes that
> > the "stack base" value is what it should set SP to, so reporting 0
> > for that will break binaries that were built with it.
> >
> > As the TODO comment notes, the "heap base" is a bit of a guess,
> > but putting stackbase at top-of-RAM seems generally sensible.
> >
> > What bug are we trying to fix here?
>
> Having newlib use a value that's wrong and therefor plant it's heap in
> the middle of the loaded code.
>
> > I think one possible implementation that might not be too
> > hard to make work would be:
> >
> > (1) find the guest physical address of the main machine
> > RAM (machine->ram). You can do this with flatview_for_each_range()
> > similar to what rom_ptr_for_as() does. (It might be mapped
> > more than once, we could just pick the first one.)
>
> Currently this is done by common_semi_find_region_base which pokes
> around get_system_memory()->subregions to find a region containing an
> initialised register pointer.
Yes. I am suggesting we throw that code away, since (a) assuming
any register happens to point in to the main RAM is dubious and
(b) iterating through the subregions of get_system_memory() is
not guaranteed to work either (consider the case where the system
memory is inside a container MR rather than a direct child of the
system memory MR).
> > (2) find the largest contiguous extent of that RAM which
> > is not covered by a ROM blob, by iterating through the
> > ROM blob data. (This sounds like one of those slightly
> > irritating but entirely tractable algorithms questions :-))
>
> Does that assume that any rom blob (so anything from -kernel, -pflash or
> -generic-loader?) will have also included space for guest data and bss?
Yes; the elf loader code creates rom blobs whose rom->romsize
covers both initialized data from the ELF file and space to
be zeroed.
thanks
-- PMM
next prev parent reply other threads:[~2021-06-10 14:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 10:26 [PATCH v2] semihosting/arm-compat: remove heuristic softmmu SYS_HEAPINFO Alex Bennée
2021-06-10 10:57 ` Peter Maydell
2021-06-10 13:55 ` Alex Bennée
2021-06-10 12:32 ` Peter Maydell
2021-06-10 14:12 ` Alex Bennée
2021-06-10 14:25 ` Peter Maydell [this message]
2021-06-11 17:01 ` Alex Bennée
2021-06-13 14:58 ` Peter Maydell
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=CAFEAcA9NYv1GdA+2P_7hbqgBwRTv6JFgfp1mS_PzURY-aafkeA@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=astrauss11@gmail.com \
--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.