Hi all;

this issue is solved and tested in 6.0.4-rc1.

The proposed  patch has also been accepted for uClibc-ng 1.0.25.

kp

Am Sonntag, 7. Mai 2017, 17:23:19 schrieb kp kirchdoerfer:
> Hi Bob, Hi Erich;
> 
> thanks for the profound work on this bug.
> 
> I've contacted the maintainer of uClibc-ng and received some homework to
> track this issue. The proposed patch by by ddrown needs testing and if
> successful, might be accepted.
> 
> kp
> 
> Am Mittwoch, 3. Mai 2017, 22:04:53 schrieb Erich Titl:
> > Hi Bob
> > 
> > (copying this to leaf-devel)
> > 
> > Sorry, I was too fast, I did not look into the i386 code but the one in
> > x86_64
> > 
> > Am 03.05.2017 um 20:03 schrieb Robert K Coffman Jr. -Info From Data Corp.:
> > > Eric,
> > > 
> > > IRC user ddrown confirmed the x64 patch I mentioned earlier seems to fix
> > > the issue on i386 as well.  I'm not really sure what to do with that
> > > information.  Is it possible to patch Leaf with it?
> > > 
> > > https://gist.github.com/ddrown/15e943b8fe1da398320b0c0518c95554
> > 
> > I don't know. It looks like the RESTORE2 macro is extended with a nop
> > operator in this patch. This looks like assembly code.
> > 
> > ...
> > 
> > This is i386...
> > 
> > #define RESTORE(name, syscall) RESTORE2(name, syscall)
> > 
> > #ifdef __NR_rt_sigaction
> > /* The return code for realtime-signals.  */
> > # define RESTORE2(name, syscall) \
> > __asm__ (                                               \
> > 
> >          ".text\n"                                       \
> >          "__" #name ":\n"                                \
> >          "       movl    $" #syscall ", %eax\n"          \
> >          "       int     $0x80\n"                        \
> > 
> > );
> > RESTORE(restore_rt, __NR_rt_sigreturn)
> > #endif
> > 
> > #ifdef __NR_sigreturn
> > /* For the boring old signals.  */
> > # undef RESTORE2
> > # define RESTORE2(name, syscall) \
> > __asm__ (                                               \
> > 
> >          ".text\n"                                       \
> >          "__" #name ":\n"                                \
> >          "       popl    %eax\n"                         \
> >          "       movl    $" #syscall ", %eax\n"          \
> >          "       int     $0x80\n"                        \
> > 
> > );
> > RESTORE(restore, __NR_sigreturn)
> > #endif
> > 
> > and this is x86_64
> > 
> > #define RESTORE(name, syscall) RESTORE2(name, syscall)
> > #define RESTORE2(name, syscall) \
> > __asm__ (                                               \
> > 
> >          "nop\n"                                         \
> >          ".text\n"                                       \
> >          "__" #name ":\n"                                \
> >          "       movq    $" #syscall ", %rax\n"          \
> >          "       syscall\n"                              \
> > 
> > );
> > 
> > #ifdef __NR_rt_sigaction
> > /* The return code for realtime-signals.  */
> > RESTORE(restore_rt, __NR_rt_sigreturn)
> > #endif
> > #ifdef __NR_sigreturn
> > RESTORE(restore, __NR_sigreturn)
> > #endif
> > 
> > So in i386 the patch appears to be possible, if it is necessary I don't
> > know as it looks like the nop operator could be used to make the
> > assembly code align to instruction size. The nop operator is already in
> > the x86_64 code.
> > 
> > I have not followed uClibc development. I am wondering what their
> > position is on this issue.
> > 
> > cheers
> > 
> > ET
> 
> ----------------------------------------------------------------------------
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> _______________________________________________
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to