Re: RFA: Need to extend x86 psABI to support thread cancellation and alternate signal stack
On 03/27/2018 12:43 AM, H.J. Lu wrote: On Linux, when alternate signal stack is used with thread cancellation, _Unwind_Resume fails when it tries to unwind shadow stack from signal handler on alternate signal stack. The issue is that signal handler on alternate signal stack uses a separate shadow stack and we must switch to the original shadow stack to unwind it. But frame count will be wrong in this case. For thread cancellation, there is no need to unwind shadow stack since it will long jump back and exit. One possibility is 1. Add _URC_NO_REASON_CANCEL. 2. unwind_stop in libpthread returns _URC_NO_REASON_CANCEL. 3. _Unwind_ForcedUnwind_Phase2 sets frames to 1 for _URC_NO_REASON_CANCEL I assume the sequence of events goes like this: 1. The program receives a signal with a SA_ONSTACK handler. 2. The program switches to the alternate signal stack (including an alternate shadow stack) and runs the handler. 3. The handler reaches a cancellation point. 4. Cancellation is acted upon. During unwinding, INCSSP is executed as needed. The switch from the alternate signal stack is implicit in the SP register restore. But there is no corresponding stack switch back to the original shadow stack. This means that INCSSP faults once the alternate stack is empty. Is this description accurate? I think this has to be fixed entirely within the libgcc unwinder. Otherwise, any application which throws from a (synchronous) signal handler will have the same issue, and I think this is something we need to support. It may be possible to implement this without kernel changes: Patch the interrupted context to continue unwinding, and then call sigreturn to switch both stacks at the same time. Thanks, Florian
Industrial routers with high?performance-price ratio and multiple functions
Dear Sir or Madam, If you're on the market for industrial routers, It will be glad to tell you that we can meet all of your requirements . Our company name is Xiamen Ursalink Technology Co,We are the manufacturer specializing on designing and producing M2M/IoT hardware and solutions. The features of our products£º 1. High-availability LTE/WCDMA/GSM connection 2. Automated fail-over between Ethernet and cellular (dual SIMs). 3. IPsec, OpenVPN, DMVPN, L2TP, GRE, PPTP for safety communication. 4. Ultra-reliable and secure data transmission via Gigabit Ethernet ports. 5. Fully integrated into Microsoft Auzure IoT eco-system, easily to be build an IoT solution. 6. Python & Ursalink SDK (Python 2.7/C) for secondary development. 7. Free 3-year warranty 8. No additional license fee (All-in-one system) 9. It can work as Modbus Master to send alerts by SMS. 10. It support TCP2COM protocol to integrate with SCADA system. ... ... Such a high performance-price ratio, with multiple functions, and high security router is your best choice,isn¡¯t it? To get more information£¬you can click here or visit www.ursalink.com . More details will be available on receipt of your reply.
RFA: Need to extend x86 psABI to support thread cancellation and alternate signal stack
On Linux, when alternate signal stack is used with thread cancellation, _Unwind_Resume fails when it tries to unwind shadow stack from signal handler on alternate signal stack. The issue is that signal handler on alternate signal stack uses a separate shadow stack and we must switch to the original shadow stack to unwind it. But frame count will be wrong in this case. For thread cancellation, there is no need to unwind shadow stack since it will long jump back and exit. One possibility is 1. Add _URC_NO_REASON_CANCEL. 2. unwind_stop in libpthread returns _URC_NO_REASON_CANCEL. 3. _Unwind_ForcedUnwind_Phase2 sets frames to 1 for _URC_NO_REASON_CANCEL BTW, I opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85086 -- H.J.
Successful bootstrap and install of gcc (GCC) 7.3.0 on armv7l-unknown-linux-gnueabi
Hi, Here's a report of a successful build and install of GCC: $ gcc-7.3.0/config.guess armv7l-unknown-linux-gnueabi $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/arm-unknown-linux-gnueabi/7.3.0/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: ../gcc-7.3.0/configure --with-arch=armv4t --with-float=soft --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=arm-unknown-linux-gnueabi --build=arm-unknown-linux-gnueabi --target=arm-unknown-linux-gnueabi --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 7.3.0 (GCC) -- Build environment -- host: raspberrypi-2 distro: los.git rootfs=f34e7 native=f34e7 kernel: Linux 4.16.0-rc6-rpi2-los_08eb5 binutils: GNU binutils 2.30 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.27. zlib: 1.2.11 mpfr: 4.0.1 gmp: 60102 -- Time consumed -- configure: real0m 20.27s user0m 16.31s sys 0m 7.55s bootstrap: real13h 26m 43s user44h 6m 26s sys 2h 6m 09s install:real9m 19.12s user3m 24.14s sys 6m 47.41s -- Hardware details --- MemTotal: 983580 kB processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 processor : 1 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 processor : 2 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 processor : 3 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 Hardware: BCM2835 Revision: A.
IBM Users Contact List
Hi, We are glad to inform you about our recent list release of IBM Users Contact List and we are know to learn your interest in acquiring the list. Likewise we can provide the information on IBM products as Well such as: IBM Watson, Mainframes, IBM as400, IBM Tivoli, IBM marketing cloud, IBM Cognos, IBM Spss and many more List Contains: Name, Title, Email, Company Name, and Company Details like, Physical Address, Web Address, Revenue Size, Employee Size and industry. If there is someone else I need to talk to within your organization, please forward this mail to that person or kindly refer me. Kind Regards Marry Bella Senior Market Analysist
Re: GSOC proposal
Hello Ismael, On Wed, Mar 21 2018, Ismael El Houas Ghouddana wrote: > Dear Mr./Mrs, > > First of all, I really appreciate your time and attention. I am Ismael El > Houas an aerospace engineer student with knowledge of Google Cloud Platform > and I want to express my interest in working on your project. I am sorry to reply only now, mainly because of traveling, I was not reading my email in the second half of last week. > > Secondly, I want to ask if I am still at a time to apply to this project, > unfortunately, I was not aware of GSOC until yesterday. In the case, I am > still able to apply for it, I will make the proposal as soon as possible. Strictly speaking, the deadline is tomorrow, as decided by the GSoC organizers. If you have been working on a proposal despite not hearing from us, we would sill like to see it and encourage you to submit it before the deadline. If you haven't, it is really getting rather late, unless you have a very clear idea of what you want to do (in that case we should still try!). My apologies again for missing you message, I hope GSoC works out for you one way or another. Martin
Re: Errors in pairs
On 03/24/2018 04:06 PM, Volker Reichelt wrote:
Hi everybody,
while bug-hunting I noticed that we emit lots of erros in pairs in
check_final_overrider (cp/search.c), e.g.:
error ("invalid covariant return type for %q+#D", overrider);
error (" overriding %q+#D", basefn);
I would expect the second line to be emitted as a note (using inform).
Is there a reason for this or should that be changed?
Probably a sign the code predates 'inform' and/or the error-limit
option. As Paolo says, this should be changed.
nathan
--
Nathan Sidwell
