On Thu, 2015-03-19 at 13:51 -0700, Roland McGrath wrote:
The XXX comment right above there says what we really want. It
the read-from-core option in its back pocket and do that only when locating
a disk file by build-id failed. I've lost track now of how much
refactoring would be required to do that.
Yes, that would be nice. But it looks like a fairly large rewrite of
dwfl_core_file_report and dwfl_build_id_find_elf. Because the second is
called "lazily" at a much later time, we'll have to keep track of what
dwfl_core_file_report already did so dwfl_build_id_find_elf can pick it
At least in Fedora/RH-flavored distros the file generally is
disk (/lib/modules/V-R.A/vdso/*.so). But I guess you still don't have a
pointer to that keyed on build-id unless you've installed the debuginfo
Yes, but only on newer versions, not on other distros and for some
reason not for linux-gate, only for "real" vdsos.
(I said years ago that someone should integrate some build-id
knowledge magic into rpm or something, so that you can readily look up by
build-id every binary installed via your package system.)
It is still a good idea.
But I can't think of a real downside to using the in-core image
when it is
the whole file. That logic applies at least as well when the data is
mmap'd, so the core->map_address check should move before the build-id
check, shouldn't it?
In the case we mmap'd the code at the top of the function would already
have triggered and returned the ELF image because the whole file would
already been read in/mmap'd in memory. So if we get to the build-id
check we know that either the file is big and incomplete, or not eagerly
read in already. It is the second case we want to check for. So the
core->map_address check should not be moved before the build-id check,
because we still only want to use the (big) mmap'd (partial) memory when
no build-id is found.
And I think you should rewrite the comment:
if (whole > MAX_EAGER_COST && mod->build_id_len > 0)
/* We can't cheaply read the whole file here, so we'd
be using a partial file. But there is a build ID that could
help us find the whole file, which might be more useful than
what we have. We'll just rely on that. */
That is nicer. I used that.