public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH v3 4/6] tests/allfcts.c: Install alternate debug information
Date: Fri, 18 Apr 2014 13:58:44 +0200	[thread overview]
Message-ID: <1397822324.29199.86.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: 3666d4ad5a9fd9f22a87529890c9a889edf81f12.1397586259.git.fweimer@redhat.com

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

On Tue, 2014-04-15 at 16:58 +0200, Florian Weimer wrote:
> This change also adds more error checking and reporting.
>
> +	* allfcts.c (setup_alt): New function.
> +	(main): Call it.  Implementation additional error checking and
> +	reporting.

> +static Dwarf *
> +setup_alt (Dwarf *main)
> +{
> +  const void *build_id;
> +  size_t build_id_len;
> +  const char *alt_name = dwelf_dwarf_gnu_debugaltlink
> +    (main, &build_id, &build_id_len);
> +  if (alt_name == NULL)
> +    return NULL;
> +  int fd = open (alt_name, O_RDONLY);
> +  if (fd < 0)
> +    err (1, "open (%s)", alt_name);
> +  Dwarf *dbg_alt = dwarf_begin (fd, DWARF_C_READ);
> +  close (fd);

I am slightly surprised this actually works. Normally you cannot just
close the fd of the underlying Dwarf (or Elf). For an Elf you can if you
force it to have been read completely into memory first by doing
elf_cntl (elf, ELF_C_FDREAD) as is currently done in try_debugaltlink.
Which you could do here (on the Elf and then call dwarf_begin_elf) if
you want to make sure to not leak the fd. But otherwise you need to keep
the fd around and close it after calling dwarf_end.

>  		  doff = dwarf_getfuncs (die, cb, NULL, doff);
> +		  if (dwarf_errno () != 0)
> +		    errx (1, "dwarf_getfuncs (%s): %s",
> +			  argv[i], dwarf_errmsg (-1));

I think this works fine, and the original code did this, but in a less
convenient way (you wouldn't get any error reported). So keep it as is.

But the way dwarf_getfuncs returns an error state is by returning -1.
Which isn't really documented and somewhat awkward, so what you do is
nicer. It is just that theoretically a callback could trigger
dwarf_errno being set and ignore that as being fine, which might be
silly, but "legal". You would then pick up a non-fatal dwarf_errno.

Cheers,

Mark


             reply	other threads:[~2014-04-18 11:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-18 11:58 Mark Wielaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-04-22  7:37 Florian Weimer
2014-04-15 14:58 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=1397822324.29199.86.camel@bordewijk.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.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).