From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66027 invoked by alias); 5 Apr 2018 06:43:36 -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 66015 invoked by uid 89); 5 Apr 2018 06:43:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.5 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=modifications, Someone, HContent-Transfer-Encoding:8bit X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: Questions about failing testcase nptl/test-mutex-printers To: libc-alpha@sourceware.org References: <3279564a-c051-1690-3b19-c7686c7753aa@redhat.com> From: Stefan Liebler Date: Thu, 05 Apr 2018 06:43: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: <3279564a-c051-1690-3b19-c7686c7753aa@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18040506-0020-0000-0000-0000040E46FD X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18040506-0021-0000-0000-000042A25899 Message-Id: <81c24c15-6a20-5d5b-cd5e-6a38f5608023@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-04-05_03:,, 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-1804050073 X-SW-Source: 2018-04/txt/msg00133.txt.bz2 On 03/28/2018 03:15 PM, Carlos O'Donell wrote: > On 03/28/2018 06:58 AM, Stefan Liebler wrote: >> Does it make sense to disable lock-elision for the pretty-printer-tests? > > Yes it does, and that is probably the correct answer in this case. > > Many of the tests rely on looking at the internal details of the lock, > particularly if you're going to pretty-print it, and elision does not allow > that to happen because the lock and any modifications are elided. > >> 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.""" > > Someone would have to confirm on at least one other arch to make sure this works > as expected. > PING. Is there anybody with an intel / power lock-elision machine who can test this?