Re: linux-user cannot allocate stack memory on riscv64 host due to non-zero guest_base

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Thu, Jun 27, 2024, 1:54 AM Andreas Schwab <schwab@suse.de> wrote:

> On Jun 26 2024, Warner Losh wrote:
>
> > On Wed, Jun 26, 2024 at 9:48 AM Richard Henderson <
> > richard.henderson@linaro.org> wrote:
> >
> >> On 6/26/24 01:23, Andreas Schwab wrote:
> >> > On Jun 25 2024, Richard Henderson wrote:
> >> >
> >> >> can always force the use of a non-zero base with -B or -R.
> >> >
> >> > $ qemu-riscv64 -d page -B 0x3ee000 hello.riscv64
> >> > host mmap_min_addr=0x1000 (fallback)
> >> > qemu-riscv64: /daten/src/test/hello.riscv64: requires virtual address
> >> space that is in use (omit the -B option or choose a different value)
> >> >
> >>
> >> Well, sure, but that obviously is where qemu-riscv64 itself is located.
> >> Still not a valid test case.
> >>
> >
> > Yea, what happens if you say -B 0x3ee000000 or something else that won't
> > conflict?
>
> I didn't chose that number, qemu did.  If it doesn't work then qemu must
> be fixed.
>

And when you are diagnosing the root cause of the bug, the submitter of the
bug sometimes needs to do diagnostic tests when requested, not attack the
volunteers who are trying to help. If that's all you do, there will be no
fix. You can't talk to me like that and expect any reaction but "I have
better things to do with my time than deal with this jerk" regardless of
the merits of the original complaint.

Warner

-- 
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>

[-- Attachment #2: Type: text/html, Size: 2518 bytes --]