To count as a real directory prefix the string matched should either
be equal to the given prefix or start with the prefix plus '/'.
skip_dir_prefix is always used with base_dir or dest_dir which don't
end with a slash themselves.
This really only is an issue if a package would put a directory named
similar to the package source dir (which cargo on fedora does, by adding
a directory named cargo-vendor in the builddir itself).
Signed-off-by: Mark Wielaard <mark@klomp.org>
The filling of the buffer, buf, that was passed to rpmfcPrint() was
removed in d16bdb15 (in 2007). Since then, an uninitialized buffer was
used if the files to calculate the dependencies for were passed as
arguments on the command line.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@gmail.com>
The fix for rhbz#444310 (commit c1a5eb - Include empty CU current dirs)
was a little greedy. It would also include comp_dirs outside the build
root. Those are unnecessary and we don't have a good way to store them.
Such dirs (e.g. /tmp) would then show up at the root of /usr/src/debug.
Fix this by including only comp_dirs under base_dir. Also only output
all dirs once (during phase zero) and don't output empty dirs (which
was harmless but would produce a warning from cpio).
This still includes all empty dirs from the original rhbz#444310
nodir testcase and it is an alternative fix for rhbz#641022
(commit c707ab).
Both fixes are necessary in case of an unexpected mode for a directory
actually in the build root that we want to include in the source list.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Some packages depend on the build-ids as generated during the build
and cannot handle rpmbuild recomputing them before generating the
package file list. Add -n, --no-recompute-build-id to debugedit and
add -n to find-debuginfo.sh set by defining the %_no_recompute_build_ids
macro for such packages. %_no_recompute_build_ids can not be used together
with %_unique_build_ids.
Signed-off-by: Mark Wielaard <mark@klomp.org>
This problem was found by ALT rpm verify-elf brp script:
verify-elf: WARNING: ./usr/lib/rpm-plugins/systemd_inhibit.so: uses non-LFS functions: __lxstat
verify-elf: WARNING: ./usr/lib/rpm/sepdebugcrcfix: uses non-LFS functions: __xstat mmap open pread pwrite
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
We would put one too many slashes in between the new dest_dir and file name
part of the replacement of a DW_FORM_string in the .debug_info. If there
was file part then we would overwrite the first character of the name. If
there was no file part at all then this would overwrite the zero terminator
and cause a crash reading the rest of the data.
A crash did happen while building the docker package on fedora s390x.
https://bugzilla.redhat.com/show_bug.cgi?id=1434347
The reason neither issue would normally trigger is because if we do detect
that the dest_dir is larger than the base_dir we refuse to replace anything.
Signed-off-by: Mark Wielaard <mark@klomp.org>
We wouldn't replace the changed file names if replace_dirs was false,
but replace_files was true. This could overrun the new debug_line data
buffer if the original file name was larger than the replacement. It
wasn't found before because often when we need to replace files we
also would have to replace dirs.
This fixes the kubernetes build in fedora.
Signed-off-by: Mark Wielaard <mark@klomp.org>
debugedit doesn't read raw mmap data any longer. Which made the complex
way to read the build-id unnecessary (and it was broken for cross-endian).
Just use gelf_getnote to read the notes.
Also in some special cases when only the debug_info or build_id data
was updated, but no section changed size and we had to preserve the
allocated section headers we could hit a bug in elfutils that could
trash some section data in case there were gaps between non-dirty and
dirty sections. See https://sourceware.org/bugzilla/show_bug.cgi?id=21199
Add a workaround for that issue.
This fixes the kompose package build on fedora ppc64.
And makes it possible to replicate that issue on x86_64.
Signed-off-by: Mark Wielaard <mark@klomp.org>
debugedit --base to --dest rewriting of debug source file paths only
supported dest paths that were smaller or equal than the base path
(and the size should differ more than 1 character for correct debug lines).
All paths were changed "in place". Which could in theory mess up debug str
sharing.
This rewrite supports base and dest strings of any size (some limitations,
see below). This is done by reconstructing the debug_str and debug_line
tables and updating the references in the debug_info attributes pointing
to these tables. Plus, if necessary (only for ET_REL kernel modules),
updating any relocations for the debug_info and debug_line sections.
This has the nice benefit of merging any duplicate strings in the
debug_str table which might resulting on slightly smaller files.
kernel modules are ET_REL files that often contain a lot of duplicate
strings.
The rewrite uses elfutils (either libebl or libdw) to reconstruct the
debug_str table. Since we are changing some section sizes now we cannot
just use mmap and rawdata to poke the values, but need to read in and
write out the changed sections. This does take a bit more memory because
we now also need to keep track of all string/line references.
There are still some limitations (already in the original debugedit)
not fixed by this rewrite:
- DW_AT_comp_dir in .debug_info using DW_FORM_string can not be made
larger. We only warn about that now instead of failing. The only
producer of DW_FORM_string comp_dirs is binutils gas. It seems simpler
to fix gas than to try to support resizing the debug_info section.
- A DW_AT_name on a DW_TAG_compile_unit is only rewritten for DW_FORM_strp
not for DW_FORM_string. Probably no problem in practice since this
wasn't supported originally either.
- The debug_line program isn't scanned for DW_LNE_define_file which
could in theory define an absolute path that might need rewriting.
Again probably not a problem because this wasn't supported before
and there are no know producers for this construct.
To support the upcoming DWARFv5 in gcc 7 (not on by default), we will
need to add support for the new debug_line format and scan the new
debug_macro section that can have references to the debug_str table.
Signed-off-by: Mark Wielaard <mark@klomp.org>
I think the reliance on bfd.h was a mistake. The code was lifted from
bfd, but should be totally independent (it just calculates a CRC).
Fix the type to be a normal size_t and include sys/stat.h (which was
included through bfd.h) to get the definitions of stat and chmod.
Introduce a new macro _unique_build_ids that when set will pass the
version and release to find-debuginfo.sh and debugedit to recalculate
the build-id of ELF files.
Includes two new testcases to make sure the new setting works as expected
both when set and unset.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Some old tools might still use the .gnu_debuglink section to find
separate debuginfo files instead of build-id style lookups. When
dwz has compresses the .debug files the original CRC in the main
ELF file will no longer match. Make sure to run sepdebugcrcfix
after dwz to recalculate the CRC.
The original fix was created by Jan Kratochvil based on code
from GNU binutils BFD. https://bugzilla.redhat.com/show_bug.cgi?id=971119
I added a testcase to make sure the CRCs were all correctly
updated after dwz has run to compress a debuginfo package.
And a change (plus testcase) to make sure implicit suid binaries
didn't accidentially got their suid flag bit.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
The RPM code contains setprogname()/getprogname() support implemented through compatiblity layer with very old GLIBC (internals supported back to '95 and earlier), before stabilization of the GNU C library. This compatiblity layer (__progname, __assert_progname, setprogname()) is supposed to support well archaic GLIBC, but on the other hand it pollutes the library namespace and introduces unpredicable compillation errors on BSD systems.
The functions setprogname() and getprogname() are natively supported in NetBSD and work the same way as __progname from the GNU C library (they are even implemented in the same way - but with a slightly changed logic). The support for very old (20 years and older) GNU C Library is obfuscating the code, because it uses defines over defines without a word of explaination why to do so.
It's important to note that the setprogname()/getprogname() was inconstiently implemented in the codebase, duplicating the code and/or functionality.
Add new generic functions getprogname() and setprogname() and bind it to:
- the current and for two decades stable GNU LIB C implementation,
- the current NetBSD implementation (introduces to NetBSD in 2002),
- fallback reimplementation functions of the setprogname() and getprogname() functionality for other systems.
Don't support anymore old GNU Lib C internals and don't support older NetBSD systems, as they aren't supported for many years.
Add to the codebase comments explaining the relevant codeparts.
- The original case of empty string ending up in a dependency is already
taken care of by commit 66a01c977e and
soname filtering. However if filtering is disabled, an an empty
(or all-whitespace) soname will produce gems like "()(64bit)" on
multilib arches, so we need to sanity check the soname itself in
elfdeps.
- The linker doesn't seem to care what kind of junk the soname contains,
we care just a little bit more as eg empty strings and whitespace
messes up other things.
AArch64 generates a relocation which must be handled similar to other
architectures. Adding this patch allows debugedit to run against the
kernel debuginfo.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- The message is not about basedir and destdir, and printing them
here only makes the message even more confusing than it was, eg:
canonicalization unexpectedly shrank by one character \
('/home/pmatilai/rpmbuild/BUILD/' vs '/usr/src/debug/')
- This reverts commit 1eea433d99
- A dependency on the interpreter is likely to be redundant, but
presence of PT_INTERP is a useful indication of whether a file
is executable or not: all normal dynamically linked executables
have it whether PIE DSO or "plain" executable. Some libraries
also have it but they are supposed to be really executable:
for example glibc's libc.so and libQtCore.so have it and print out
config, version etc information when executed.
- For now, we dont actually use the PT_INTERP information for anything
apart from the optional require.
- Instead of vain heuristics on DT_SONAME presence, filter out
irregular sonames from all dependencies: linkable library names generally
must contain ".so" and start with "lib" for the linker to find it at all,
anything else is an exception of one kind or another (the prime exception
of ld.so variants we handle here). This weeds out provides for most
dlopen()'ed modules etc, and filtering both provides and requires
by the same rules means we wont generate requires for things that wont be
provided. Of course this also means we can omit things that are in
DT_NEEDED, but these should be rare exceptions which the new
--no-filter-soname switch is for.
- (Private) libraries which might intentionally not have DT_SONAME
are still recorded as requires from DT_NEEDED, and there's no
way of knowing what's an internal library when generating requires.
Not faking the soname in these cases will only result in broken
requires in cases that always used to "just work".
- Change the switch to --no-fake-soname disabler instead to allow
tweaking in special cases but by default we gotta match linker
(and ELF specification) behavior, no matter how much we'd like to
use this for our own heuristics :-/
- Remember DT_SONAME in the elfInfo struct if encountered and
only add it after everything else has been processed. This doesn't
change any actual functionality for now, but gives us a single
place where to control the addition.
- Additionally document what the related DT_DEBUG test is for and
clean up the processDynamic() loop and switch-case a bit.
- This helps cutting down the number of bogus provides from dlopen()'ed
plugins and internal libraries which preferrably shouldn't have a
soname at all. Unfortunately libtool always puts in a soname even if
-module -avoid-version is used :-/
- OTOH there are broken libraries which dont have a soname even though
they should, so (we need to) allow falling back to the former behavior
of faking up a soname from the basename.
- Determine arch-specific issues by looking at the elf header instead
of compile-time #ifdefs, so we'll generate correct dependencies for
non-native elf binaries too. Currently this is just alpha which despite
being a 64bit system, never had the (64bit) markers in its dependencies.
Of course alpha has pretty much already met its mark^H^H er maker by now,
but doing the right thing is cheap... Also we'll need similar special
cases sooner or later for other archs (such as x32).
- Commit a25c3c7bac removed what was
supposedly a non-supported method of passing files as arguments
(instead of the normal stdin method) to rpmdeps. Turns out
rpmdeps is even documented to take files as cli args, and that's
how Fedora's %filter_setup macros are calling it...
- Allow files as arguments again, but in a way that doesn't cause
argvFoo() vs popt crash-n-burn.
- debugedit doesn't support STABS but there are some crazy cases
like PPC Linux kernel which contains both STABS and DWARF debuginfo
sections, manually added. A better fix would be erroring out
if we didn't find any usable debuginfo and warning otherwise but
this at least folks get their kernels built.
- Both relate to reading manifests and it doesn't make the damnest
difference what io mode these use as rpmReadPackageManifest()
opens its own stream on the fd with fdopen() which works on
any io type, not just fpio..
- The common pattern here is grabbing current flags to a local
variable, modifying them for an operation and then restoring,
which is fine... but we dont care about the previous flags
when we're restoring them.
- Depgen helpers take nno args, their input comes from stdin. Eliminates
popt vs ARGV_t mismatch which would've caused us to blow up if
it weren't for a memleak on the generated argv.
- Another memleak on the file classifier in case rpmfcClassify()
or rpmfcApply() fails - just free all allocated resources at exit.
- Remove fluff: fgets() is guaranteed to \0-terminate non-NULL returns,
eliminate unused/useless variables
- Fixup indentation where busted
- The previous "silently ignore" policy produces bogus debuginfo
packages on some architectures and fails with other mysterious
errors on others, better just fail hard until (if ever) somebody adds
stabs support.
- rpmfcClassify() or rpmfcApply() failing is pretty fatal to rpmdeps,
exit with error code
- OTOH argvAdd() and argvSort() can't really fail, ignore their return
codes, shutting up another set-but-not-used whine
- It contains piles of buffer overflow etc material and AFAIK this
has been unused for its entire lifespan of > 10 years, fixing
an unused piece of code seems like a waste of time. If somebody
shows interest later on it can be resurrected, but in the meanwhile...
Mark Wielaard