Hi Rich, On 07/24/2013 07:55 AM, Rich Felker wrote: > On Wed, Jul 24, 2013 at 07:34:07AM +0200, Michal Simek wrote: >> Microblaze was assign to CLONE_BACKWARDS type where >> parent tid was passed via 3rd argument. >> Microblaze glibc is using 4th argument for it. >> >> 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. > 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. In my email you can see that I have also asked about tools which should be used for kernel API testing. > I think the broken > userspace software that was already failing to work due to this > mismatch should simply be fixed rather than adding incompatible kernel > ABI variants. The incompatibility is between glibc register setup and the kernel sys_clone register expectation which doesn't match right now. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature