[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 2/2] tests/tcg: port SYS_HEAPINFO to a system test
From: |
Peter Maydell |
Subject: |
Re: [PATCH v4 2/2] tests/tcg: port SYS_HEAPINFO to a system test |
Date: |
Wed, 9 Feb 2022 17:44:54 +0000 |
On Wed, 9 Feb 2022 at 17:26, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Wed, 23 Jun 2021 at 14:48, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> This allows us to check our new SYS_HEAPINFO implementation generates
> >> sane values.
> >>
> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >> ---
> >> tests/tcg/aarch64/system/semiheap.c | 74 +++++++++++++++++++++++++++++
> >> 1 file changed, 74 insertions(+)
> >> create mode 100644 tests/tcg/aarch64/system/semiheap.c
> >> + /*
> >> + * We don't check our local variables are inside the reported
> >> + * stack because the runtime may select a different stack area (as
> >> + * our boot.S code does). However we can check we don't clash with
> >> + * the heap.
> >> + */
> >> + if (ptr_to_info > info.heap_base && ptr_to_info < info.heap_limit) {
> >> + ml_printf("info appears to be inside the heap: %p in %p:%p\n",
> >> + ptr_to_info, info.heap_base, info.heap_limit);
> >
> > I'm not sure this test is valid -- the 'struct info' is on our stack,
> > so it could be anywhere in RAM, including possibly in the big
> > range we got back from SYS_HEAPINFO.
>
> 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.
*/
?
-- PMM