public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@sourceware.org>
To: DJ Delorie <dj@redhat.com>
Cc: fweimer@redhat.com, libc-alpha@sourceware.org
Subject: Re: [PATCH 4/8] mcheck: Wean away from malloc hooks
Date: Mon, 28 Jun 2021 11:52:33 +0530	[thread overview]
Message-ID: <5dab6be6-d3f9-60d3-868f-b42aad7ceb0e@sourceware.org> (raw)
In-Reply-To: <xn7dii7u69.fsf@greed.delorie.com>

On 6/25/21 4:21 AM, DJ Delorie via Libc-alpha wrote:
> 
> Siddhesh Poyarekar <siddhesh@sourceware.org> writes:
>> Initialization using -lmcheck now depends on a new exported variable
>> __libc_lmcheck which is a const flag that mcheck-init can override.
> 
> I wonder if we should bite the bullet and add an official malloc_ioctl()
> or something.  Oh wait, we have mallopt() already.  Can we hijack this
> instead of adding an ABI?
> 
>    mallopt (MALLOC_INTERNAL_GET_VER, 0) returns malloc_version + 1000
>    (or returns 0 or 1, for "not supported")
> 
>    mallopt (MALLOC_INTERNAL_SET_DEBUG, debug_flags)
> 
> This could be done in a .ctor/.init; I wonder if that would be early
> enough.

It won't be; it is likely that a ctor preceding the DSO that was linked 
with -lmcheck could call malloc and hence result in ptmalloc_init being 
called before the ctor mallopt is called.

I reckon it has to be an ELF hack.  An exported symbol like 
__libc_lmcheck seems like the cleanest way to do it.

We could add an ELF note, but typically notes don't impact execution so 
that seems like a bad idea.

We could add a specially named segment (e.g. .glibc.lmcheck) with no 
contents (or a single nop word) that ld.so reads to decide if mcheck 
should be enabled.  However that's not too different from __libc_lmcheck 
in terms of ABI impact (we don't add a symbol version but its absence 
will have the same effect) with the added complexity in the dynamic linker.

>> -  if (__glibc_unlikely (__is_malloc_debug_enabled (MALLOC_CHECK_HOOK)))
>> +  if (__glibc_unlikely (__malloc_debugging_hooks))
>>       {
>> -      *victimp = malloc_check (bytes);
>> -      if (*victimp != NULL)
>> -	memset (*victimp, 0, bytes);
>> -      return true;
>> +      if (__is_malloc_debug_enabled (MALLOC_MCHECK_HOOK)
>> +	  && malloc_mcheck_before (bytesp, victimp))
>> +	return true;
>> +      if (__is_malloc_debug_enabled (MALLOC_CHECK_HOOK))
>> +	{
>> +	  *victimp = malloc_check (*bytesp);
>> +	  return true;
> 
> memset missing?  no, moved to below...  A comment would help here.

Added comment.

>> +static __always_inline void *
>> +_calloc_debug_after (void *mem, size_t bytes, const void *address)
>> +{
>> +  if (__glibc_unlikely (__malloc_debugging_hooks) && mem != NULL)
>> +    {
>> +      if (__is_malloc_debug_enabled (MALLOC_MCHECK_HOOK))
>> +	mem = malloc_mcheck_after (mem, bytes);
>> +      memset (mem, 0, bytes);
>> +    }
>> +  return mem;
>> +}
> 
> So we memset if *any* hook is called, ok.
> 
>> diff --git a/malloc/malloc.c b/malloc/malloc.c
>> index 60753446a1..5ea12d1d3b 100644
>> --- a/malloc/malloc.c
>> +++ b/malloc/malloc.c
>> @@ -3192,12 +3192,13 @@ __libc_malloc (size_t bytes)
>>   {
>>     mstate ar_ptr;
>>     void *victim;
>> +  size_t orig_bytes = bytes;
> 
> Do we need to initialize victim to NULL here?

All paths initialize victim, but I've initialized it anyway and left it 
to the compiler to optimize it away.

Thanks,
Siddhesh

  reply	other threads:[~2021-06-28  6:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24 18:23 [PATCH 0/8] Remove " Siddhesh Poyarekar
2021-06-24 18:23 ` [PATCH 1/8] Move glibc.malloc.check implementation into its own file Siddhesh Poyarekar
2021-06-24 19:57   ` DJ Delorie
2021-06-28  4:34     ` Siddhesh Poyarekar
2021-06-24 18:23 ` [PATCH 2/8] malloc: Move malloc hook references to hooks.c Siddhesh Poyarekar
2021-06-24 21:10   ` DJ Delorie
2021-06-24 18:23 ` [PATCH 3/8] glibc.malloc.check: Wean away from malloc hooks Siddhesh Poyarekar
2021-06-24 21:43   ` DJ Delorie
2021-06-24 18:23 ` [PATCH 4/8] mcheck: " Siddhesh Poyarekar
2021-06-24 22:51   ` DJ Delorie
2021-06-28  6:22     ` Siddhesh Poyarekar [this message]
2021-06-24 18:23 ` [PATCH 5/8] mtrace: " Siddhesh Poyarekar
2021-06-24 23:13   ` DJ Delorie
2021-06-28  6:25     ` Siddhesh Poyarekar
2021-06-24 18:23 ` [PATCH 6/8] Remove " Siddhesh Poyarekar
2021-06-24 23:31   ` DJ Delorie
2021-06-28  6:37     ` Siddhesh Poyarekar
2021-06-24 18:23 ` [PATCH 7/8] Remove __after_morecore_hook Siddhesh Poyarekar
2021-06-24 23:33   ` DJ Delorie
2021-06-24 18:23 ` [PATCH 8/8] Remove __morecore and __default_morecore Siddhesh Poyarekar
2021-06-24 23:38   ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5dab6be6-d3f9-60d3-868f-b42aad7ceb0e@sourceware.org \
    --to=siddhesh@sourceware.org \
    --cc=dj@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).