All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Andrew <astrauss11@gmail.com>, qemu-arm <qemu-arm@nongnu.org>
Subject: Re: [RFC PATCH] semihosting/arm-compat: remove heuristic softmmu SYS_HEAPINFO
Date: Tue, 01 Jun 2021 11:04:17 +0100	[thread overview]
Message-ID: <87fsy1dhke.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA-zzg4Yh0pX2q-9OfFKEbX_uGkVb_8kZbQJJETLRo_zOQ@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 1 Jun 2021 at 10:12, Alex Bennée <alex.bennee@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.bennee@linaro.org>
>> Cc: Andrew <astrauss11@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.

>
> thanks
> -- PMM


-- 
Alex Bennée

WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Andrew <astrauss11@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>
Subject: Re: [RFC PATCH] semihosting/arm-compat: remove heuristic softmmu SYS_HEAPINFO
Date: Tue, 01 Jun 2021 11:04:17 +0100	[thread overview]
Message-ID: <87fsy1dhke.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA-zzg4Yh0pX2q-9OfFKEbX_uGkVb_8kZbQJJETLRo_zOQ@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 1 Jun 2021 at 10:12, Alex Bennée <alex.bennee@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.bennee@linaro.org>
>> Cc: Andrew <astrauss11@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.

>
> thanks
> -- PMM


-- 
Alex Bennée


  reply	other threads:[~2021-06-01 10:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-01  9:07 [RFC PATCH] semihosting/arm-compat: remove heuristic softmmu SYS_HEAPINFO Alex Bennée
2021-06-01  9:07 ` Alex Bennée
2021-06-01  9:14 ` Peter Maydell
2021-06-01  9:14   ` Peter Maydell
2021-06-01 10:04   ` Alex Bennée [this message]
2021-06-01 10:04     ` Alex Bennée
2021-06-01 10:30     ` Peter Maydell
2021-06-01 10:30       ` Peter Maydell
2021-06-01 10:52       ` Andrew Strauss
2021-06-01 10:52         ` Andrew Strauss
2021-06-01 10:54 ` Andrew Strauss
2021-06-01 10:54   ` Andrew Strauss

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=87fsy1dhke.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=astrauss11@gmail.com \
    --cc=peter.maydell@linaro.org \
    --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.