From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101180 invoked by alias); 4 Dec 2017 15:42:53 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 100357 invoked by uid 89); 4 Dec 2017 15:42:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,URIBL_DBL_ABUSE_SPAM autolearn=no version=3.3.2 spammy=restored, Different X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH] S390: Fix backtrace in vdso functions. To: libc-alpha@sourceware.org References: <6698d098-aea3-14cc-8ed7-762def848dc9@linaro.org> From: Stefan Liebler Date: Mon, 04 Dec 2017 15:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 17120415-0040-0000-0000-000003F638E8 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120415-0041-0000-0000-000025F92A51 Message-Id: <3cc167ed-3ffe-11d4-9d4c-dfbe3cf1fb2d@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-04_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712040226 X-SW-Source: 2017-12/txt/msg00074.txt.bz2 On 12/04/2017 11:47 AM, Adhemerval Zanella wrote: > > > On 04/12/2017 05:59, Stefan Liebler wrote: >> On 11/28/2017 02:09 PM, Adhemerval Zanella wrote: >>> >>> >>> On 28/11/2017 10:44, Stefan Liebler wrote: >>>> Hi, >>>> >>>> On s390, GDB fails to show the complete backtrace from within vdso functions. The macro INTERNAL_VSYSCALL_CALL saves the return address in r14 to r10 before branching to the vdso function. The branch-instruction updates r14 in order to let the vdso function return. Then the original address in r14 is restored from r10. Unfortunately, there are no cfi-rules and GDB fails. >>>> >>>> Furthermore the call of the vdso function does not comply with the s390 ABI as no stack-frame for the vdso-function is generated. >>>> >>>> This patch removes the s390 specific macro INTERNAL_VSYSCALL_CALL and the common implementation in sysdeps/unix/sysv/linux/sysdep-vdso.h is used. Then the vdso function is called via function-pointer and GCC generates a new stack-frame and emits all needed cfi-rules. >>>> >>>> The defines CLOBBER_[0-6] are removed as they  were only used in macro INTERNAL_VSYSCALL_CALL. >>>> >>>> The macro INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK is not used on s390. The only user is power. Thus it is removed from s390 sysdep.h. >>> >>> I am almost sure we can remove it for powerpc as well (I can't see >>> no immediate gain on doing a function call using inline assembly >>> as for INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK on powerpc). >>> >>> >>>> >>>> ChangeLog: >>>> >>>>      * sysdeps/unix/sysv/linux/s390/s390-64/sysdep.h >>>>      (INTERNAL_VSYSCALL_CALL, CLOBBER_0, CLOBBER_1, CLOBBER_2, >>>>       CLOBBER_3, CLOBBER_4, CLOBBER_5, CLOBBER_6, >>>>      INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK): Remove. >>>>      * sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h: Likewise. >>> >>> Reviewed-by: Adhemerval Zanella >>> >> >> If there are no objections regarding the s390 patch, I'll commit. >> >> Adhemerval: Do you keep working on removing INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK on powerpc? > > Different than s390 where the an error is indicate through a negative value, > powerpc signals an error through CR0.SO. And __kernel_clock_getres and > __kernel_clock_gettime fallback to a syscall call in case the timers are > not supported through vDSO, which requires we check CR0.SO value. I do > not a reliable way to check it after a function call on GCC (we can issue > a volatile assembly after it, but I think it is still fragile and it > would require a arch-specific wrapper anyway). > > There is also the issue with __kernel_get_tbfreq which returns a 64 bit > value for powercp32, so we need another wrapper that does expect the return > code as long int. > Okay. Then I've just committed this patch.