public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Carlos O'Donell <carlos@redhat.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	DJ Delorie <dj@redhat.com>
Subject: Re: [PATCH] libc: Extend __libc_freeres framework (Bug 23329).
Date: Wed, 27 Jun 2018 09:46:00 -0000	[thread overview]
Message-ID: <b63ae101-282c-d5b6-bdf5-b5347c2420b8@redhat.com> (raw)
In-Reply-To: <a27c1dea-d4c6-95ec-b531-541837d997ec@redhat.com>

On 06/27/2018 05:06 AM, Carlos O'Donell wrote:

> diff --git a/include/libc-symbols.h b/include/libc-symbols.h
> index 6137304b0b..89a5604ee7 100644
> --- a/include/libc-symbols.h
> +++ b/include/libc-symbols.h

> +/* Resource pointers to freed in libc.so.  */
> +#define libc_freeres_ptr(decl) \
> +  __make_section_unallocated ("__libc_freeres_ptrs, \"aw\", %nobits") \
> +  decl __attribute__ ((section ("__libc_freeres_ptrs" __sec_comment)))
> +
> +/* Resource freeing functions from libc.so.  */
> +#define __libc_freeres_fn_section \
> +  __attribute__ ((section ("__libc_freeres_fn")))

These are okay.

> +/* Resource freeing functions for threads in libc.so.  */
> +#define __libc_thread_freeres_fn_section \
> +  __attribute__ ((section ("__libc_thread_freeres_fn")))

This is an unrelated change.  I think you should drop it.  Since these 
functions run during normal operation, it is unclear whether placing 
them into a separate section is actually beneficial.

> +/* Resource freeing functions for libdl.so  */
> +#define __libdl_freeres_fn_section \
> +  __attribute__ ((section ("__libdl_freeres_fn")))
> +
> +/* Resource freeing functions for libpthread.so.  */
> +#define __libpthread_freeres_fn_section \
> +  __attribute__ ((section ("__libpthread_freeres_fn")))

I suggest to drop those as well, for now.  The reason is that you didn't 
add placement for the section in the linker script.

> diff --git a/malloc/set-freeres.c b/malloc/set-freeres.c
> index f4a0e7bda4..9e0de0c403 100644
> --- a/malloc/set-freeres.c
> +++ b/malloc/set-freeres.c
> @@ -26,6 +26,10 @@ DEFINE_HOOK (__libc_subfreeres, (void));
>   
>   symbol_set_define (__libc_freeres_ptrs);
>   
> +extern __attribute__((weak)) void __libdl_freeres (void);
> +
> +extern __attribute__((weak)) void __libpthread_freeres (void);
> +

Missing space after __attribute__.  I think that's the current convention.

>   void __libc_freeres_fn_section
>   __libc_freeres (void)
>   {
> @@ -39,8 +43,19 @@ __libc_freeres (void)
>   
>         _IO_cleanup ();
>   
> +      /* We run the resource freeing after IO cleanup.  */
>         RUN_HOOK (__libc_subfreeres, ());
>   
> +      /* Call the libdl list of cleanup functions
> +	 (weak-ref-and-check).  */
> +      if (&__libdl_freeres != NULL)
> +	call_function_static_weak (__libdl_freeres);
> +
> +      /* Call the libpthread list of cleanup functions
> +	 (weak-ref-and-check).  */
> +      if (&__libpthread_freeres != NULL)
> +	call_function_static_weak (__libpthread_freeres);

Weak declared twice here.  I think you should call these functions 
directly, without call_function_static_weak.

Rest looks okay, thanks.

Florian

  reply	other threads:[~2018-06-27  9:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27  3:06 Carlos O'Donell
2018-06-27  9:46 ` Florian Weimer [this message]
2018-06-28  4:15   ` [PATCH v2] " Carlos O'Donell
2018-06-28 12:13     ` Florian Weimer
2018-06-28 13:07       ` [PATCH v3] " Carlos O'Donell
2018-06-28 13:22         ` Florian Weimer
2018-06-28 13:36           ` [PATCH v4] " Carlos O'Donell
2018-06-28 13:44             ` Florian Weimer
2018-06-28 14:13               ` Carlos O'Donell
2018-06-28 14:15                 ` Florian Weimer
2018-06-28 14:26                   ` Carlos O'Donell
2018-06-28 14:50                     ` Florian Weimer
2018-06-28 19:03                 ` Andreas Schwab
2018-06-28 19:10                   ` Florian Weimer
2018-07-02  8:56                     ` Andreas Schwab

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=b63ae101-282c-d5b6-bdf5-b5347c2420b8@redhat.com \
    --to=fweimer@redhat.com \
    --cc=carlos@redhat.com \
    --cc=dj@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).