From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101786 invoked by alias); 12 Apr 2018 13:54:24 -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 101771 invoked by uid 89); 12 Apr 2018 13:54:23 -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,KHOP_DYNAMIC,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=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> <81c24c15-6a20-5d5b-cd5e-6a38f5608023@linux.vnet.ibm.com> From: Stefan Liebler Date: Thu, 12 Apr 2018 13:54: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: <81c24c15-6a20-5d5b-cd5e-6a38f5608023@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18041213-0012-0000-0000-000005CA143E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18041213-0013-0000-0000-000019464AB9 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-12_07:,, 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-1804120138 X-SW-Source: 2018-04/txt/msg00207.txt.bz2 On 04/05/2018 08:43 AM, Stefan Liebler wrote: > 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? > PING