All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
To: ltp@lists.linux.it
Subject: [LTP] reason of pwritev01_64 failure on 32-bit arm
Date: Fri, 2 Sep 2016 18:58:51 +0300	[thread overview]
Message-ID: <27af95c6-76ee-20f1-15e3-d84d729c1738@dev.rtsoft.ru> (raw)

Hi,

I've reproduced and analyzed failure of pwritev01_64 described at [1]

[1] http://lists.linux.it/pipermail/ltp/2016-March/001201.html


pwritev01_64 fail is an LTP issue

pwrite01 and pwrite01_64 are built from the same source, pwrite01.c
64-bit version is built with additional define, -D_FILE_OFFSET_BITS=64,
which causes 'off_t' type defined by glibc to become 64-bit.

Problem is that both pwrite01.o and pwrite01_64.o link against the same
utility library, libltp
From this library, a routine called safe_pread() is used.
One of arguments of this routine has type off_t.
This means that ABI for this routine is different when built with
-D_FILE_OFFSET_BITS=64 and without it.
Library is built without -D_FILE_OFFSET_BITS=64, thus on 32-bit platform
safe_pread() inside library expects ABI with 32-bit 'off_t'. And
pwrite01_64.o, built with -D_FILE_OFFSET_BITS=64, uses different ABI.

If a copy of safe_pread() is injected inside pwrite01.c (and compile
issue is resolved), test passes.

In general, it is not safe to link together object files built with and
without -D_FILE_OFFSET_BITS=64, since that code is not always
binary-compatible.


On 64-bit platform, sizeof(off_t) is 8 both with and without
-D_FILE_OFFSET_BITS=64, this issue does not show.

WBR,
Nikita Yushchenko

             reply	other threads:[~2016-09-02 15:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02 15:58 Nikita Yushchenko [this message]
2016-09-05 10:54 ` [LTP] reason of pwritev01_64 failure on 32-bit arm Jan Stancek
2016-09-27 11:58   ` [LTP] [PATCH] safe_macros: make safe_pread() and safe_pwrite() inline Nikita Yushchenko
2016-09-27 12:56     ` Cyril Hrubis
2016-11-26  8:30       ` Nikita Yushchenko
2016-11-28 15:45         ` Cyril Hrubis

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=27af95c6-76ee-20f1-15e3-d84d729c1738@dev.rtsoft.ru \
    --to=nyushchenko@dev.rtsoft.ru \
    --cc=ltp@lists.linux.it \
    /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.