From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4433 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: stat64 on mips Date: Mon, 30 Dec 2013 16:29:53 -0500 Message-ID: <20131230212953.GL24286@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388439000 18579 80.91.229.3 (30 Dec 2013 21:30:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Dec 2013 21:30:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4437-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 30 22:30:07 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VxkPX-0004Af-5K for gllmg-musl@plane.gmane.org; Mon, 30 Dec 2013 22:30:07 +0100 Original-Received: (qmail 17884 invoked by uid 550); 30 Dec 2013 21:30:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17876 invoked from network); 30 Dec 2013 21:30:06 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4433 Archived-At: On Mon, Dec 30, 2013 at 06:20:46PM +0000, Justin Cormack wrote: > MIPS is the most confusing architecture, but as far as I can make out, > the definition of struct stat64 that Musl has is probably the right > one for mips n32 but wrong for mips o32 which should be > > struct stat { > unsigned long st_dev; > unsigned long __st_pad0[3]; > unsigned long long st_ino; > mode_t st_mode; > nlink_t st_nlink; > uid_t st_uid; > gid_t st_gid; > unsigned long st_rdev; > unsigned long __st_pad1[3]; > long long st_size; > time_t st_atime; > unsigned long st_atime_nsec; > time_t st_mtime; > unsigned long st_mtime_nsec; > time_t st_ctime; > unsigned long st_ctime_nsec; > unsigned long st_blksize; > unsigned long __st_pad2; > long long st_blocks; > }; > > It does appear that the syscalls for the two ABIs differ in this... This structure is identical to the one in musl except that it has 32-bit dev_t plus padding in place of 64-bit dev_t, and the musl version has reserved space at the end. Can you check whether the dev_t issue is actually a problem (it might be, based on endianness, and if so I think it would require ugly fixups in userspace)? Rich