public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Nick Alcock <nick.alcock@oracle.com>, binutils@sourceware.org
Subject: Re: [PATCH 03/19] libctf: lowest-level memory allocation and debug-dumping wrappers
Date: Thu, 02 May 2019 15:29:00 -0000	[thread overview]
Message-ID: <4cda9c6e-c285-6b97-614f-4d7aaf3a036f@redhat.com> (raw)
In-Reply-To: <20190430225706.159422-4-nick.alcock@oracle.com>

Hi Nick,

> I could easily be convinced that all of these wrappers serve no purpose
> and should be globally removed, but the debugging tracer is frequently
> useful, and the malloc/free/mmap/munmap wrappers have proved mildly
> useful in conjunction with symbol interposition for allocation debugging
> in the (relatively distant) past.

I see no problem with retaining these wrappers.  They are not going to inflict
a large overhead on the library, and if they have proved helpful in debugging
then they have proved their worth.  Besides having functions like these allows
them to be intercepted by third parties, if for some reason that becomes
necessary.

> (I am amenable to replacing the environment-variable triggering of
> ctf_dprintf() with something else in the binutils commit,

I am not a fan of using environment variables, although in this particular
case it is not so bad.  There is of course the problem of documentation -
you must tell the users about the variable - and also the fact that users
of the library might wish to enable/disable debugging themselves.  Perhaps
the library could provide a function to set the value of _libctf_debug even
after _libctf_init() has been called ?

> +/* Miscellary.
> +   Copyright (C) 2003-2019 Free Software Foundation, Inc.
> +

Ooo - just noticed - this header, and others too, do not mention who
contributed the code.  It would be nice to see your efforts acknowledged
don't you think ?


> +void *
> +ctf_data_alloc (size_t size)
> +{
> +  return (mmap (NULL, size, PROT_READ | PROT_WRITE,
> +		MAP_PRIVATE | MAP_ANON, -1, 0));
> +}

I am not a memory allocation expert - but is it efficient to
call mmap for every memory allocation ?  Or do higher levels
of libctf manage the allocated memory so that this function is
only used when needed to grab large chunks of memory ?


> +void
> +ctf_data_free (void *buf, size_t size)
> +{
> +  (void) munmap (buf, size);
> +}

Why do you ignore and discard the return value from munmap() ?
If there is an error, surely you would want to examine it or
return it to the caller ?


> +void
> +ctf_free (void *buf, size_t size _libctf_unused_)
> +{
> +  free (buf);
> +}

Why does your free function have a size parameter at all ?


> +_libctf_printflike_ (1, 2)
> +void ctf_dprintf (const char *format, ...)
> +{
> +  if (_libctf_debug)
> +    {
> +      va_list alist;
> +
> +      va_start (alist, format);
> +      (void) fputs ("libctf DEBUG: ", stderr);
> +      (void) vfprintf (stderr, format, alist);

I would recommend calling "fflush (stdout)" before starting to
print to stderr, just in order to make sure that the debug output
does not appear halfway through a line of ordinary output.

Cheers
  Nick

  reply	other threads:[~2019-05-02 15:29 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30 22:57 [PATCH 00/19] libctf, and CTF support for objdump and readelf Nick Alcock
2019-04-30 22:57 ` [PATCH 04/19] libctf: low-level list manipulation and helper utilities Nick Alcock
2019-05-02 16:04   ` Nick Clifton
2019-05-03 19:25     ` Nick Alcock
2019-04-30 22:57 ` [PATCH 11/19] libctf: core type lookup Nick Alcock
2019-04-30 22:57 ` [PATCH 14/19] libctf: library version enforcement Nick Alcock
2019-04-30 22:57 ` [PATCH 03/19] libctf: lowest-level memory allocation and debug-dumping wrappers Nick Alcock
2019-05-02 15:29   ` Nick Clifton [this message]
2019-05-03 19:12     ` Nick Alcock
2019-04-30 22:57 ` [PATCH 12/19] libctf: lookups by name and symbol Nick Alcock
2019-04-30 22:57 ` [PATCH 09/19] libctf: opening Nick Alcock
2019-04-30 22:57 ` [PATCH 06/19] libctf: hashing Nick Alcock
2019-05-02 16:16   ` Nick Clifton
2019-05-03 19:33     ` Nick Alcock
2019-04-30 22:57 ` [PATCH 10/19] libctf: ELF file opening Nick Alcock
2019-04-30 22:57 ` [PATCH 02/19] include: new header ctf-api.h Nick Alcock
2019-05-02 15:07   ` Nick Clifton
2019-05-03 11:23     ` Nick Alcock
2019-04-30 22:57 ` [PATCH 05/19] libctf: error handling Nick Alcock
2019-05-02 16:10   ` Nick Clifton
2019-05-03 19:31     ` Nick Alcock
2019-04-30 22:57 ` [PATCH 15/19] libctf: mmappable archives Nick Alcock
2019-04-30 22:57 ` [PATCH 13/19] libctf: type copying Nick Alcock
2019-04-30 22:57 ` [PATCH 01/19] include: new header ctf.h: file format description Nick Alcock
2019-05-01 16:57   ` Nick Clifton
2019-05-01 21:29     ` Jim Wilson
2019-05-03 11:15       ` Nick Alcock
2019-04-30 22:57 ` CTF format overview Nick Alcock
2019-04-30 22:57 ` [PATCH 08/19] libctf: creation functions Nick Alcock
2019-04-30 22:57 ` [PATCH 19/19] binutils: CTF support for objdump and readelf Nick Alcock
2019-04-30 22:58 ` [PATCH 18/19] libctf: build system Nick Alcock
2019-05-01  0:13 ` [PATCH 17/19] libctf: debug dumping Nick Alcock
2019-05-01  0:19 ` [PATCH 16/19] libctf: labels Nick Alcock
2019-05-01  1:57 ` [PATCH 07/19] libctf: implementation definitions related to file creation Nick Alcock
2019-05-01 16:02 ` [PATCH 00/19] libctf, and CTF support for objdump and readelf Nick Clifton
2019-05-01 16:16   ` Jose E. Marchesi
2019-05-03 10:47     ` Nick Alcock
2019-05-02 15:22 ` Joseph Myers
2019-05-03 12:33   ` Nick Clifton
2019-05-06 16:40     ` Nick Alcock
2019-05-08 14:34     ` Michael Matz
2019-05-08 16:01       ` Nick Clifton
2019-05-08 16:20         ` Nick Alcock
2019-05-03 14:23   ` Nick Alcock
     [not found]     ` <alpine.DEB.2.21.1905072117440.19308@digraph.polyomino.org.uk>
2019-05-08 11:39       ` Nick Alcock
2019-05-24  8:57     ` Pedro Alves
2019-05-24 16:05       ` Nick Alcock
2019-05-24 16:19         ` Pedro Alves
2019-05-24 20:09           ` Nick Alcock
2019-05-03 16:19 ` Florian Weimer
2019-05-03 19:45   ` Nick Alcock
2019-05-06 12:07     ` Florian Weimer

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=4cda9c6e-c285-6b97-614f-4d7aaf3a036f@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=nick.alcock@oracle.com \
    /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).