mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] remaining steps for time64 switchover
Date: Tue, 29 Oct 2019 15:53:57 -0400	[thread overview]
Message-ID: <20191029195357.GH16318@brightrain.aerifal.cx> (raw)
In-Reply-To: <20191029195245.GG16318@brightrain.aerifal.cx>

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

On Tue, Oct 29, 2019 at 03:52:45PM -0400, Rich Felker wrote:
> On Sun, Oct 20, 2019 at 10:46:43PM -0400, Rich Felker wrote:
> > The attached patch series on top of present git master (commit
> > 9b2921bea1d5017832e1b45d1fd64220047a9802) should contain all changes
> > needed for fully working time64 on 32-bit archs, in a form that's
> > plausibly ready for commit (no makeshift hacks just to get things
> > demonstrably working). The one omission I'm aware of is what to do
> > with struct utmpx, which is not actually used at present in any libc
> > interfaces and thus not part of the ABI surface of libc. That will be
> > addressed in a separate thread.
> > 
> > Comments and basic testing are welcome at this point. It should be
> > possible to build for any of the 32-bit archs, but I have only tested
> > build for a few and only tested execution on i386 and sh.
> > 
> > Some useful checks for anyone wanting to help test, especially on the
> > more obscure archs:
> > 
> > [...]
> > 
> > - Anything look odd about time-related types? timeval/timespec members
> >   at positions that aren't naturally aligned?
> 
> I tested this on i386 (with low alignment requirement, only 4 bytes)
> with the attached program and it seems like I indeed got the padding
> slots as-intended on the ipc types. This should mean the adjacent
> explicit-padding members have no effect on other archs using the same
> changes but with natural alignment, which matches the intent. As usual
> mips and ppc are gratuitously different and seemed right to me but
> should perhaps be double-checked at some point. However since they
> have natural alignment the worst that could happen is leaving extra
> padding slots we don't need.

Attachment forgotten, here. Usage is to build against the appropriate
libc/headers and save output, then diff outputs as desired.

Rich


[-- Attachment #2: offsets.c --]
[-- Type: text/plain, Size: 1226 bytes --]


#include <stddef.h>
#include <stdio.h>
#include <sys/sem.h>
#include <sys/shm.h>
#include <sys/msg.h>
#include <sys/stat.h>

#define O(s,m) printf("offsetof(%s, %s)==%zd\n", #s, #m, offsetof(s,m))

int main()
{
	O(struct semid_ds, sem_perm);
	O(struct semid_ds, sem_otime);
	O(struct semid_ds, sem_ctime);
	O(struct semid_ds, sem_nsems);

	O(struct shmid_ds, shm_perm);
	O(struct shmid_ds, shm_segsz);
	O(struct shmid_ds, shm_atime);
	O(struct shmid_ds, shm_dtime);
	O(struct shmid_ds, shm_ctime);
	O(struct shmid_ds, shm_cpid);
	O(struct shmid_ds, shm_lpid);
	O(struct shmid_ds, shm_nattch);

	O(struct msqid_ds, msg_perm);
	O(struct msqid_ds, msg_stime);
	O(struct msqid_ds, msg_rtime);
	O(struct msqid_ds, msg_ctime);
	O(struct msqid_ds, msg_cbytes);
	O(struct msqid_ds, msg_qnum);
	O(struct msqid_ds, msg_qbytes);
	O(struct msqid_ds, msg_lspid);
	O(struct msqid_ds, msg_lrpid);

	O(struct stat, st_dev);
	O(struct stat, st_ino);
	O(struct stat, st_mode);
	O(struct stat, st_nlink);
	O(struct stat, st_uid);
	O(struct stat, st_gid);
	O(struct stat, st_rdev);
	O(struct stat, st_size);
	O(struct stat, st_blksize);
	O(struct stat, st_blocks);
	O(struct stat, st_atim);
	O(struct stat, st_mtim);
	O(struct stat, st_ctim);
}

  reply	other threads:[~2019-10-29 19:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21  2:46 Rich Felker
2019-10-21 12:43 ` Rich Felker
2019-10-27  4:15   ` Rich Felker
2019-10-27  4:26 ` Rich Felker
2019-10-27  8:32   ` Laurent Bercot
2019-10-27 14:53     ` Rich Felker
2019-10-27 20:12     ` Matias Fonzo
2019-10-27 21:14       ` Rich Felker
2019-10-27 21:53         ` Matias Fonzo
2019-10-27 23:27           ` Laurent Bercot
2019-10-28 21:31             ` Matias Fonzo
2019-10-28 22:22   ` Rich Felker
2019-10-29 19:52 ` Rich Felker
2019-10-29 19:53   ` Rich Felker [this message]
2019-10-29 23:08 ` Rich Felker

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=20191029195357.GH16318@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).