public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH v3 4/6] tests/allfcts.c: Install alternate debug information
Date: Tue, 22 Apr 2014 09:37:40 +0200	[thread overview]
Message-ID: <53561C44.4050006@redhat.com> (raw)
In-Reply-To: 1397822324.29199.86.camel@bordewijk.wildebeest.org

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

On 04/18/2014 01:58 PM, Mark Wielaard wrote:
> 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.

Yes, now I'm surprised as well. :-)

> 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.

I went this route.

>>   		  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.

I added this check because when I still had an actual error code (not 
zero) for the missing .gnu_debugaltlink section in 
dwelf_dwarf_gnu_debugaltlink, the test case broke in a slightly 
non-obvious way.

-- 
Florian Weimer / Red Hat Product Security Team

             reply	other threads:[~2014-04-22  7:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-22  7:37 Florian Weimer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-04-18 11:58 Mark Wielaard
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=53561C44.4050006@redhat.com \
    --to=fweimer@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).