From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123747 invoked by alias); 19 Apr 2018 10:50:46 -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 123738 invoked by uid 89); 19 Apr 2018 10:50:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 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= X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: Questions about failing testcase nptl/test-mutex-printers To: libc-alpha@sourceware.org References: <87po2wwpbt.fsf@linux.ibm.com> From: Stefan Liebler Date: Thu, 19 Apr 2018 10:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87po2wwpbt.fsf@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18041910-0040-0000-0000-00000430B8BA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18041910-0041-0000-0000-00002634CEEB Message-Id: <30d6e019-0776-f8f7-ce49-4a76601ff6bd@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-19_04:,, 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1804190097 X-SW-Source: 2018-04/txt/msg00392.txt.bz2 On 04/18/2018 04:40 PM, Tulio Magno Quites Machado Filho wrote: > 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. > Thanks. Committed: https://sourceware.org/git/?p=glibc.git;a=commit;h=0085be1415a38b40a5a1a12e49368498f1687380