This is the mail archive of the
mailing list for the binutils project.
Re: Question: short-read while loading .so file
- From: "ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Binutils <binutils at sourceware dot org>
- Date: Sat, 06 Jun 2015 04:55:13 +0900
- Subject: Re: Question: short-read while loading .so file
- Authentication-results: sourceware.org; auth=none
- Authentication-results: access07.SiriusCloud.jp; dkim=none (no signature) header.i=unknown; x-dkim-adsp=none (insecure policy)
- References: <5571C58F dot 9050600 at yk dot rim dot or dot jp> <5571C94F dot 9000302 at arm dot com>
On 2015/06/06 1:07, Szabolcs Nagy wrote:
> On 05/06/15 16:51, ISHIKAWA,chiaki wrote:
>> My surprise was that during the test of mozilla thunderbird when I
>> I injected the "short read" to a few files, I made a mistake of
>> applying short tread to a few .so files and
>> I observed that these *.so files were dynamically loaded by such short
> dynamic linker is a libc issue so send the report
> to libc-alpha instead of binutils mailing list.
> (assuming you use glibc).
I should have known. I was under the impression that linking (and
loading implicitly was handled by binutils package.)
I will ask libc-alpha mailing list.
>> That is, when the request to read these relatively small .so files by
>> |read| with requested # of octets being 4096, my hand-crafted prelaoded
>> |read| reads only 4036 (4096 - 60) octets, but
>> the dynamic loader did not request the remaining 60 octets, and merrily
>> went on running.
>> My question is:
>> Does the loader handle "short read" properly by issuing additional
>> |read| if it notices that it needs to read more octets which are missing
>> from the data structure read partially by the first |read|?
>> Or was I just lucky that the last 60 octets (and presumably more octets
>> before the last 60 octets) were mere fillers and the real code and data
>> lived only the initial portion of 4096 octets, and that the failure to
>> read the last 60 octets did not cause any issues in this particular run?
> sounds like a bug, but libc-alpha will know better
Thank you for your pointer again.
>> Yes, the mozilla thunderbird did not crash or anything although no
>> additional read was issued to read the remaining 60 octets.
>> That is why I am asking this question.
>> Thank you in advance for your attention.
>> Best Regards,
>> Chiaki Ishikawa