Bug#791985: Please support ARM64 (ucontext_t)
* Guy deve...@faert.net [2015-07-14 08:52]: My tests showed that this behaviour is different today. I don't know whether a change in the kernel or libc is the reason, but it looks as if the arch specififc code is no longer needed and thus, in libguytools 2.0.4, it has been commented out. 2.0.4 is available on Sourceforge. Thanks for looking into this, Guy! -- Martin Michlmayr Linux for HP Helion, Hewlett-Packard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791985: Please support ARM64 (ucontext_t)
I checked again the source code and made some tests. For what I saw, that arch specififc code is no longer needed. On older systems, backtrace() returned everything but the instruction pointer of the place where the segmentation fault occured (obviously the most interesting one). This was due to the way how signal handling worked. The arch specific code tried to fetch the corresponding address and store it in the array before passing it to backtrace_symbols() for looking up the function names. My tests showed that this behaviour is different today. I don't know whether a change in the kernel or libc is the reason, but it looks as if the arch specififc code is no longer needed and thus, in libguytools 2.0.4, it has been commented out. 2.0.4 is available on Sourceforge. Another thing that needs attention: Due to several code optimisations, notably frame pointer elimination (but others also), backtracing not always works. The code in toolsignal.cpp should be regarded as a best effort for getting valuable information in case a program causes a segfault. Guy Voncken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791985: Please support ARM64 (ucontext_t)
Hello Mika and Martin, I used to have some i386 and amd64 specific assembler code for hash calculation in Guymager (not libguytools) in the past, but it always was backed up by C-code for other architectures. The reason for limiting Guymager to i386, amd64 and powerpc is that I have no real HW for testing with other architectures. For libguytools it's a bit different. Those few lines mentioned by Martin are in fact architecture dependent - and I know of no way to do it differently (please correct me if I'm wrong). Fortunately, arm and arm64 should be easy to add. It set up an arm64 VM in qemu yesterday and I'll test it next week. I'll let you know about the result and the necessary changes in toolsignal.cpp. Greetings Guy On 10.07.2015 12:12, Michael Prokop wrote: Hi Martin :) Cc-ing Guy, upstream of libguytools + guymager * Martin Michlmayr [Thu Jul 09, 2015 at 03:32:01PM -0400]: Package: libguytools2 Version: 2.0.3-1 Severity: wishlist User:debian-...@lists.debian.org Usertags: arm64 port This package fails to build on arm64, but a quick looks suggests this package might be useful on arm64. Do you know if upstream or someone else is working on arm64 support (aarch64) already? The only arch specific code I could fine was in toolsignal.cpp: #if defined(__i386__) pIP = (void*) pUContext-uc_mcontext.gregs[REG_EIP]; #elif defined(__x86_64__) pIP = (void*) pUContext-uc_mcontext.gregs[REG_RIP]; #elif defined(__hppa__) pIP = (void*) pUContext-uc_mcontext.sc_iaoq[0] ~0x3UL; #elif (defined (__ppc__)) || (defined (__powerpc__)) pIP = (void*) pUContext-uc_mcontext.regs-nip; #endif The only consumer of libguytools is guymager, which itself is Architecture: amd64 i386 powerpc only (due to some architecture specific optimizations for performance reasons AFAIK), so I'm not sure what Guy as upstream thinks of that. Opinions? :) regards, -mika- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791985: Please support ARM64 (ucontext_t)
I dropped upstream for this comment since it's Debian specific. * Michael Prokop m...@debian.org [2015-07-10 12:12]: The only consumer of libguytools is guymager, which itself is Architecture: amd64 i386 powerpc only (due to some architecture specific optimizations for performance reasons AFAIK), so I'm not sure what Guy as upstream thinks of that. Opinions? :) FWIW, armhf was added in a NMU but seeing the code I mentioned in my original I wonder if it actually works on armhf... -- Martin Michlmayr Linux for HP Helion, Hewlett-Packard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791985: Please support ARM64 (ucontext_t)
Hi Martin :) Cc-ing Guy, upstream of libguytools + guymager * Martin Michlmayr [Thu Jul 09, 2015 at 03:32:01PM -0400]: Package: libguytools2 Version: 2.0.3-1 Severity: wishlist User: debian-...@lists.debian.org Usertags: arm64 port This package fails to build on arm64, but a quick looks suggests this package might be useful on arm64. Do you know if upstream or someone else is working on arm64 support (aarch64) already? The only arch specific code I could fine was in toolsignal.cpp: #if defined(__i386__) pIP = (void*) pUContext-uc_mcontext.gregs[REG_EIP]; #elif defined(__x86_64__) pIP = (void*) pUContext-uc_mcontext.gregs[REG_RIP]; #elif defined(__hppa__) pIP = (void*) pUContext-uc_mcontext.sc_iaoq[0] ~0x3UL; #elif (defined (__ppc__)) || (defined (__powerpc__)) pIP = (void*) pUContext-uc_mcontext.regs-nip; #endif The only consumer of libguytools is guymager, which itself is Architecture: amd64 i386 powerpc only (due to some architecture specific optimizations for performance reasons AFAIK), so I'm not sure what Guy as upstream thinks of that. Opinions? :) regards, -mika- signature.asc Description: Digital signature
Bug#791985: Please support ARM64 (ucontext_t)
Package: libguytools2 Version: 2.0.3-1 Severity: wishlist User: debian-...@lists.debian.org Usertags: arm64 port This package fails to build on arm64, but a quick looks suggests this package might be useful on arm64. Do you know if upstream or someone else is working on arm64 support (aarch64) already? The only arch specific code I could fine was in toolsignal.cpp: #if defined(__i386__) pIP = (void*) pUContext-uc_mcontext.gregs[REG_EIP]; #elif defined(__x86_64__) pIP = (void*) pUContext-uc_mcontext.gregs[REG_RIP]; #elif defined(__hppa__) pIP = (void*) pUContext-uc_mcontext.sc_iaoq[0] ~0x3UL; #elif (defined (__ppc__)) || (defined (__powerpc__)) pIP = (void*) pUContext-uc_mcontext.regs-nip; #endif -- Martin Michlmayr Linux for HP Helion, Hewlett-Packard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
