From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 6B2CB3858400; Fri, 8 Oct 2021 21:47:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B2CB3858400 Received: by mail-ed1-x530.google.com with SMTP id z20so41058870edc.13; Fri, 08 Oct 2021 14:47:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g4CYxuKqsMJ8iUAL+JpJtP392fsYgOVsVehw4FUjZe8=; b=KwL5+4MFPdNAqfRN41NciB23bwIBismUPpcRt0D4bohHZ44YeFo0xjOfBO/2FRUqYx AMsCW/XpboWNBI6KTx5jjSl5SPCTD3Avbr54VzKRtglFOeeYy2VmAYxtCx/ciYcDhzcv 6QhnJCky6h44TaaTDD0vSzvmcvxYJYHo077DGRRynEePkYXCu3wPsFqmWH7Y0YIYtPWh zE8zAoMtgGC38l8XZ8YYPUISae+GT6I21b/54K4ycL9phZub0SCfmHz6pRIkqm8Wd3CW UudTLgsJv2QdBuWrJudX2MU8mULsGipfKG+JXdTzYzOFbMyuJarGC3PVsh/BX7tTSQlL eIcg== X-Gm-Message-State: AOAM532lh1m3HxfRh51Duk5a5paGAhRnq1IBGujreVGVuXabZ3myFp9w fgl620PoRTpVvWvyE3r6GljFgV+9tvYKdA2sIuH00fggs4o= X-Google-Smtp-Source: ABdhPJzRmSxBlOmho+sFEDss0Lris7nVXn22SbejSFz2mpyjerYlBO6FYYDXMBf+USP5xqSVrckR8VQMZPML0GKMP2Y= X-Received: by 2002:a05:6402:5112:: with SMTP id m18mr10577115edd.101.1633729657036; Fri, 08 Oct 2021 14:47:37 -0700 (PDT) MIME-Version: 1.0 References: <20210719184637.1225275-1-siddhesh@sourceware.org> In-Reply-To: <20210719184637.1225275-1-siddhesh@sourceware.org> From: Stafford Horne Date: Sat, 9 Oct 2021 06:47:25 +0900 Message-ID: Subject: Re: [PATCH v10 00/11] malloc hooks removal To: Siddhesh Poyarekar Cc: GLIBC patches , Florian Weimer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 21:47:39 -0000 On Tue, Jul 20, 2021 at 3:48 AM Siddhesh Poyarekar via Libc-alpha wrote: > > This patchset removes the malloc hooks __malloc_hook, __free_hook, > __realloc_hook and __memalign_hook from the API and leaves compatibility > symbols so that existing applications can continue to link to them. The > reading and execution of the hooks has been moved to a DSO > libc_malloc_debug.so, which can be preloaded for applications that need > it. By default these hooks no longer have any effect in the library. > > Further, debugging features such as MALLOC_CHECK_, mcheck() and mtrace > have been weaned away from these hooks and also moved to > libc_malloc_debug.so. With this change, these features are only enabled > when libc_malloc_debug.so is preloaded using LD_PRELOAD. > > Finally, the __morecore, __morecore_after_hook and __default_morecore > hooks have also been moved to compat symbols and removed from the API. > Existing applications will continue to link to them but they won't have > any effect on malloc behaviour. Hello, I am working on an OpenRISC port and have just rebased and picked up this series. I also have updated the api version to 2.35. After this all of the mtrace related *-mem tests seem to be failing. Is this expected to be completely removed after going to 2.35 and the compatibility APIs get compiled out? If so, then the tests should be skipped, if not then then something is broken for glibcs with base version 2.35: For example: cat sysdeps/unix/sysv/linux/or1k/shlib-versions DEFAULT GLIBC_2.35 ld=ld-linux-or1k.so.1 FAIL: posix/bug-glob2-mem FAIL: posix/bug-regex14-mem FAIL: posix/bug-regex2-mem FAIL: posix/bug-regex21-mem FAIL: posix/bug-regex31-mem FAIL: posix/bug-regex36-mem FAIL: malloc/tst-mtrace. When I have looked into mtrace I can see a few strange things: In libc.so mtrace is a nop (that seems to be what you wanted for this series). 000b5bb4 : b5bb4: 44 00 48 00 l.jr r9 b5bb8: 15 00 00 00 l.nop 0x0 000b5bbc : b5bbc: 44 00 48 00 l.jr r9 b5bc0: 15 00 00 00 l.nop 0x0 Also, I am also seeing basically nothing in libc_malloc_debug.so either: < shorne@antec ~/work/gnu-toolchain/build-glibc > nm ../build-glibc/malloc/libc_malloc_debug.so 000000f4 r __abi_tag 00004020 b completed.0 w __cxa_finalize@GLIBC_2.35 00000314 t deregister_tm_clones 00000404 t __do_global_dtors_aux 00003f0c d __do_global_dtors_aux_fini_array_entry 00004000 d __dso_handle 00003f10 a _DYNAMIC 00000484 t frame_dummy 00003f08 d __frame_dummy_init_array_entry 0000048c r __FRAME_END__ 00000000 A GLIBC_2.35 00004004 a _GLOBAL_OFFSET_TABLE_ w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable 0000037c t register_tm_clones 00004004 d __TMC_END__ -Stafford