From: "Alex Bennée" <alex.bennee@linaro.org>
To: Stephen Long <steplong@quicinc.com>
Cc: peter.maydell@linaro.org, richard.henderson@linaro.org,
mjt@tls.msk.ru, laurent@vivier.eu, qemu-devel@nongnu.org,
philippe.mathieu.daude@gmail.com, ben@decadent.org.uk
Subject: Re: [PATCH] linux-user/elfload: Fix handling of pure BSS segments
Date: Wed, 25 Nov 2020 09:39:38 +0000 [thread overview]
Message-ID: <874kldixlx.fsf@linaro.org> (raw)
In-Reply-To: <20201124184754.247-1-steplong@quicinc.com>
Stephen Long <steplong@quicinc.com> writes:
> Hi Peter,
>
>> (a) what does "fails to load" mean here? In the sample binary
>> I had, we got a SIGSEGV in zero_bss() when it tried to memset()
>> memory that hadn't been mmap()ed. Is that the only failure mode,
>> or can this manifest in other ways too?
>
> Apologies for the unclear commit msg. I was also seeing a SIGSEGV in
> zero_bss() with the binaries I was generating. I was using LLD to generate
> the binaries. The binaries all had LOAD segments with a file size of
> 0.
How hairy is the generation of these binaries? If it's all doable with
standard gcc/ldd command lines it would be useful to add them as a
tcg/multiarch test case.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919921 was the thread that
> Philippe pointed me to with the requested change that solved my issue.
>
>> (b) The comment immediately before this change says:
>> * Some segments may be completely empty without any backing file
>> * segment, in that case just let zero_bss allocate an empty buffer
>> * for it.
>> which is justifying why it was looking at p_filesz and not vaddr_len.
>> With this change to the code, the comment becomes stale and needs
>> updating.
>
> I'll update the comment and the commit msg if this change makes sense to
> everybody.
>
>> (c) After this change, are there still cases where zero_bss()
>> needs to do its mmap()/page_set_flags(), or does that become
>> unnecessary ?
>
> Maybe someone else can speak to this. But, you might be right. I don't see
> this being necessary anymore.
>
> Thanks,
> Stephen
--
Alex Bennée
next prev parent reply other threads:[~2020-11-25 9:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 16:52 [PATCH] linux-user/elfload: Fix handling of pure BSS segments Stephen Long
2020-11-24 17:32 ` Richard Henderson
2020-11-24 17:38 ` Peter Maydell
2020-11-24 18:47 ` Stephen Long
2020-11-25 9:39 ` Alex Bennée [this message]
2020-12-02 17:44 ` Peter Maydell
2020-12-01 20:09 ` Stephen Long
2020-12-02 13:29 ` Alex Bennée
2020-12-02 17:14 ` Stephen Long
2020-12-17 9:41 ` Laurent Vivier
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=874kldixlx.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=ben@decadent.org.uk \
--cc=laurent@vivier.eu \
--cc=mjt@tls.msk.ru \
--cc=peter.maydell@linaro.org \
--cc=philippe.mathieu.daude@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=steplong@quicinc.com \
/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.