On Tue, 1 Jun 2021 at 11:07, Alex Bennée <alex.ben...@linaro.org> wrote: > > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > On Tue, 1 Jun 2021 at 10:12, Alex Bennée <alex.ben...@linaro.org> wrote: > >> > >> The previous numbers were a guess at best. While we could extract the > >> information from a loaded ELF file via -kernel we could still get > >> tripped up by self decompressing or relocating code. Besides sane > >> library code has access to the same symbols in run time to make a > >> determination of the location of the heap. > >> > >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > >> Cc: Andrew <astraus...@gmail.com> > >> --- > >> semihosting/arm-compat-semi.c | 19 ++++++++++--------- > >> 1 file changed, 10 insertions(+), 9 deletions(-) > > > > This seems like a pretty good candidate for breaking existing > > working binaries. How much testing against different varieties of > > guest-code-using-semihosting have you done ? > > None, which is why it's an RFC - but at least one user reported newlib > attempts to use the numbers we gave it rather than falling back to > numbers it knew from the build and getting it wrong. I suspect any code > that doesn't have a fallback path is getting it right more by luck than > judgement though. I'd be curious to hear of code that relies on the > numbers it gets from QEMU.
Well, newlib is the main one I had in mind -- does it have a fallback codepath? -- PMM
