From: Petr Machata <pmachata@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH] Support 1-sized reads in read_ubyte_unaligned_inc and read_sbyte_unaligned_inc
Date: Thu, 11 Sep 2014 01:46:10 +0200 [thread overview]
Message-ID: <m21trj3upp.fsf@redhat.com> (raw)
In-Reply-To: 20140910212207.4D23F2C39D0@topped-with-meat.com
[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]
Roland McGrath <roland@hack.frob.com> writes:
> But, in actual fact, there are zero uses of read_sbyte_unaligned_inc and
> two uses of read_ubyte_unaligned_inc (they are adjacent in
> readelf.c:print_debug_frame_section). In both of those uses the size
> argument is a non-constant, so adding another case has runtime cost.
> Clearly that cost doesn't actually matter much in readelf, but it calls
> into question the wisdom of expanding these to more uses without
> considering their performance in those uses.
The performance implications did cross my mind, and I decided that it's
fine in readelf. (I did check the uses.)
> It also seems questionable from a source-comprehensibility perspective to
> make those support a different set of sizes than read_sbyte_unaligned and
> read_ubyte_unaligned do. But those have no uses at all, so perhaps they
> should just be removed anyway.
Actually I didn't notice the two other macros. I agree that such
inconsistency is bad.
That read_sbyte_unaligned_inc should be dropped did actually come to my
mind. Clearly it's untested and untestable as things currently stand.
> How many new uses are you adding, and what do they look like? I guess they
> must have non-constant size parameters too, or you would have just used the
> size-specific macros. So where does the size parameter come from that it
> can have any of the four possible sizes?
Five, four of them with constant size and one with a 64bit?8:4 sort of
expression. The reads are done through a macro that checks bounds,
There's one macro for all the widths, mostly because I didn't like to
have four macros with unknown cut'n'paste errors. I expect that the
compiler will be able to see through and just inline a check and an
access for the right width directly, but I didn't actually check.
Admittedly this is all somewhat moot. I don't check bounds with LEB's
anyway, and most of libdw just checks post fact that the pointers are
still in bounds. Maybe I should simply do the same.
Thanks,
PM
next reply other threads:[~2014-09-10 23:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 23:46 Petr Machata [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-09-12 12:24 Petr Machata
2014-09-11 22:16 Roland McGrath
2014-09-10 21:22 Roland McGrath
2014-09-10 21:09 Petr Machata
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=m21trj3upp.fsf@redhat.com \
--to=pmachata@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).