Re: [microblaze-linux] [RESEND PATCH] microblaze: Fix clone syscall

From: Rich Felker
Date: Wed Jul 24 2013 - 03:00:29 EST

On Wed, Jul 24, 2013 at 08:48:27AM +0200, Michal Simek wrote:
> >> Create new CLONE_BACKWARDS3 type where stack_size is passed
> >> via 3rd argument, parent thread id pointer via 4th,
> >> child thread id pointer via 5th and tls value as 6th
> >> argument
> >
> > I believe this also affects us in musl. What is the motivation for
> > making a configure option that results in there being two incompatible
> > syscall ABIs for the same arch?
> > This sounds like a really bad idea...
> This patch fixes bug which was introduced by Al's patch where he moved
> clone implementation from microblaze folder to generic location.
> It means I am not creating two incompatible syscalls ABIs but fixing
> broken one.

So this patch is just fixing a regression in the kernel?

> > And how was glibc successfuly using a form that mismatched the
> > existing kernel? Did nobody ever use/test it?
> We are running LTP syscall tests and there is not LTP test which
> was able to find out this mismatch in clone. That's why I haven't
> figure it out at that time and ACKed that origin patch.

I would think pthread_create would have broken pretty badly; I
remember early-on in porting musl to microblaze, we had the clone
arguments misordered, and it blew up badly. ;) Perhaps you could just
run some general libc/libpthread level tests to catch things like this
that are hard to measure at the syscall-test level with existing

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at