[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: |
Alex Bennée |
Subject: |
Re: [PATCH v4 2/2] tests/tcg: port SYS_HEAPINFO to a system test |
Date: |
Wed, 09 Feb 2022 18:14:41 +0000 |
User-agent: |
mu4e 1.7.7; emacs 28.0.91 |
Peter Maydell <peter.maydell@linaro.org> writes:
> 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.
> */
>
> ?
Well the data segment (but not the bss). So as long as the ELF loader
includes that in the calculation (which it should I think) then we are
ok.
>
> -- PMM
--
Alex Bennée