From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83400 invoked by alias); 18 Apr 2018 14:40:19 -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 83389 invoked by uid 89); 18 Apr 2018 14:40:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=transactions, somebody X-HELO: mx0a-001b2d01.pphosted.com From: Tulio Magno Quites Machado Filho To: Stefan Liebler , GNU C Library Cc: Martin Galvan , Andi Kleen , Adhemerval Zanella , raji@linux.vnet.ibm.com, Andreas Arnez Cc: Subject: Re: Questions about failing testcase nptl/test-mutex-printers In-Reply-To: References: User-Agent: Notmuch/0.25 (http://notmuchmail.org) Emacs/25.3.1 (x86_64-redhat-linux-gnu) Date: Wed, 18 Apr 2018 14:40:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 18041814-0020-0000-0000-00000DC256FE X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008877; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000257; SDB=6.01019731; UDB=6.00520250; IPR=6.00798972; MB=3.00020640; MTD=3.00000008; XFM=3.00000015; UTC=2018-04-18 14:40:12 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18041814-0021-0000-0000-000060F5D79F Message-Id: <87po2wwpbt.fsf@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-18_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1804180131 X-SW-Source: 2018-04/txt/msg00311.txt.bz2 Stefan Liebler writes: > As I don't have access to other lock-elision enabled machines, > can somebody test this on power / intel? Tested on powerpc. Same behavior. > If I step manually to the tbegin-instruction (which starts the > transaction on s390x) and step over it, then gdb steps over the whole > transaction and we are just after the tend-instruction. That behavior also happens on powerpc with all kinds of transactions. But it's the GDB behavior with transactions on powerpc. I don't know the details on s390x. > Does it make sense to disable lock-elision for the pretty-printer-tests? > E.g. with the following patch: > diff --git a/scripts/test_printers_common.py > b/scripts/test_printers_common.py > index 73ca525556..d74a8b4d4b 100644 > --- a/scripts/test_printers_common.py > +++ b/scripts/test_printers_common.py > @@ -171,6 +171,9 @@ def init_test(test_bin, printer_files, printer_names): > # Finally, load the test binary. > test('file {0}'.format(test_bin)) > > + # Disable lock elision. > + test('set environment GLIBC_TUNABLES glibc.elision.enable=0') > + > def go_to_main(): > """Executes a gdb 'start' command, which takes us to main.""" LGTM. -- Tulio Magno