qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] semihosting/arm-compat: remove heuristic softmmu SYS_HEAP


From: Peter Maydell
Subject: Re: [PATCH v2] semihosting/arm-compat: remove heuristic softmmu SYS_HEAPINFO
Date: Thu, 10 Jun 2021 15:25:44 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]