Re: [Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)
So... I was about to ask how come this then works:
```
%{?__debug_package:%{__debug_install_post}}\
%{__arch_install_post}\
%{__os_install_post}\
%{nil}
```
...but the answer is that *it doesn't*. The debug foobar gets appended to
noarch package %install too, contrary to obvious intention of the original
author. And okay, this can easily be witnessed by the debug*.list files
appearing in the build directory of a noarch package, they're just unused as
the %debug_package macro expands to nothing on noarch packages.
Wacko :sweat_smile:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1198#issuecomment-675357458___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
Thanks, will tweak the PR accordingly. And yeah, I agree otherwise. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-675362444___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
Took more than one night of sleeping over, but here's what I think: Threading support in general is completely optional, and lack of it doesn't deprive anybody of any functionality, just a little bit of time. This is stark contrast to, say, Lua support. So I think we can easily afford to demand a newer version here than we could do for some other feature. Lets go with requiring OpenMP 4.5, it'll simplify other things in turn. The configure check might want a little tweak though: default to autodetection, and only error out if explicit --enable-openmp is given but OpenMP is too old. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-675326483___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove support for redundant %_filter_GLIBC_PRIVATE mechanism (#1333)
This was kinda ugly-but-necessary when added back in 2003 (commit 752cac72e220dcad4e6fce39508e714e59e3e0a1) but entirely redundant since the new dependency generator in rpm = 4.9.x with arbitrary filtering support. The handful of packages using it can just as well achieve the same (and more) without special hacks in rpm with: %global __requires_exclude GLIBC_PRIVATE %global __provides_exclude GLIBC_PRIVATE You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1333 -- Commit Summary -- * Remove support for redundant %_filter_GLIBC_PRIVATE mechanism -- File Changes -- M fileattrs/elf.attr (4) M macros.in (4) M tools/elfdeps.c (11) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1333.patch https://github.com/rpm-software-management/rpm/pull/1333.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1333 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)
Having revisited this again, I think I have a better grasp of the whole
mechanism now. And it's way simpler than I originally thought.
First of all, there's no such thing as "support for conditionals inside macro
definitions". Macros are just that - they may contain arbitrary text to be
substituted by them, including other macros which are expanded recursively.
Now, since `%if` is not a macro per se, it won't get expanded into anything and
just pushed to the parser for further processing (which includes conditional
parsing). As a result, spec directives found inside conditionals (that are
found inside macros) are a valid construct.
In fact, we ourselves have been using this *for years* in the `%debug_package`
macro shipped with RPM:
```
%debug_package \
%ifnarch noarch\
%global __debug_package 1\
%_debuginfo_template\
%{?_debugsource_packages:%_debugsource_template}\
%endif\
%{nil}
```
That being said, there's a catch. Since conditionals are only evaluated *after*
recursive macro expansion, the `%__debug_package` macro above will *always* be
set to 1, regardless of whether `BuildArch` is `noarch`. I think this was
(quite understandably) misunderstood when the macro was written. Another
example is the one I gave in the previous comment where "hello" is always
printed due to the fact that `echo` gets expanded (and executed) before the
conditional is.
In any case, bringing back the original functionality makes sense after all,
and I'll post a PR shortly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1198#issuecomment-675338506___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Define shell to use with $() (#1334)
It would be nice to be able to define which shell should be used with `%()` given that `/bin/sh` is not the same shell on all distros. Additionally having to write `$()` macros to the lowest common denominator is just ugly. It's much nicer to just make _bash_ a `BuildRequires:` and be able to write bashisms in`%$()`. Particularly given that most(?) distros do use bash for `/bin/sh` and only a few outliers don't. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
%_buildshell is for building, %() is macro engine builtin which has no place following rpmbuild -level macro definitions. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675453265___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
Can't you run `%(/usr/bin/bash)`? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675481660___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
My understanding is that this should be tied to the `%_buildshell` macro already. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675450997___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
So something like a `%_macroshell` would be a better idea, perhaps. But I'm not sure. I'll need to run a more comprehensive search in the code base first, to be able to make an educated guess :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675476325___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@pmatilai good point. That being said, @Conan-Kudo has pointed out that we do
in fact respect `%_buildshell` in other, non-build related areas as well. Doing
a quick grep reveals for example:
`macros.in:%__spec_prep_shell%{___build_shell}`
Still, that doesn't mean we should follow that trend, especially given that
macro processing really is a separate step in the whole spec building process.
Also, making `%()` suddenly use `%_buildshell` could cause unexpected things to
happen in spec file which already redefine it. For consistency's sake, on the
other hand, it would make sense to reuse it...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675472264___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
> This is not unlike [setting SHELL in > Makefiles](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html). +1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675499466___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
Yeah, I deleted that comment after realizing I misunderstood @voxik's question, but thinking again, it really is not a bad idea at all! It would be easier than having to redefine `%_macroshell` (or whatever we'd call it) and also cleaner, as you say. It would also get rid of the problem with "how do we pass the script body into a non-shell-like interpreter" that I mentioned above. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675530398___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@voxik I can't see why Ruby (or python, or awk, or any other interpreter) would not work. As for _supported_, that's not my call. But as you point out, this does allow the spec writer more flexibility in what interpreter their spec evaluates macros, but does require them to define the shell in their spec to get something other than the default `/bin/sh`. This is not unlike [setting SHELL in Makefiles](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675493794___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
So will Ruby by supported as well? Not that I really care, but what starts simple might provoke questions like these. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675489249___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
Sure you can. It's worth noting that this RFE is mostly cosmetic; being able to redefine a macro shell would allow you to replace all the `%(/usr/bin/bash -c "...")` calls with `%(...)`, as well as avoid spawning a shell just to spawn another shell. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675484426___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@voxik That's an interesting idea. You could then do something like `%(ruby: ...)` or `%(python: ...)` or what have you. Sounds cool. Not sure about the impact of this in a broader sense, but I don't see any reason it couldn't be done. That said, doing something just because "we can" doesn't always translate well into the maintenance side of things :) But if there are real-life use cases that would be improved with this, I think we'd open for that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675497790___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
Oh, I think I misunderstood. As @brianjmurrell said above, any interpreter would work, yes :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675500681___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
I'm yet to understand if there are any security implications by allowing to redefine the shell in a macro, though. But we already allow that for building anyway, and building a spec file is no different from running a regular shell script after all (you should audit the spec file before doing so). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675505485___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugedit: Implement DWARF-5. (#1332)
On Mon, 17 Aug 2020 10:57:59 +0200, Mark Wielaard wrote: > The commit summary is "Implement DWARF-5", but it mixes that plus > support for an alternative compiler and debug-types in one commit. > Would it be possible to split this in 3 patches, one for basic DWARF-5 > support, one for testing against an alternative compiler (which I > assume also includes an alternative .debug_line representation from > what gcc produces) and one for debug-types in DWARF5? One cannot separate "basic DWARF-5 support" from "alternative compiler" as GCC does not implement much of DWARF-5. Jan ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH 5/5] debugedit: Implement DWARF-5.
diff --git a/ci/Dockerfile b/ci/Dockerfile
index d8b0115bd..2e872be5f 100644
--- a/ci/Dockerfile
+++ b/ci/Dockerfile
@@ -45,6 +45,7 @@ RUN dnf -y install \
pkgconfig \
/usr/bin/gdb-add-index \
dwz \
+ clang llvm \
&& dnf clean all
COPY . .
diff --git a/tests/debugedit.at b/tests/debugedit.at
index bcd86ac67..5fa2bf6a7 100644
--- a/tests/debugedit.at
+++ b/tests/debugedit.at
@@ -22,8 +22,9 @@ AT_BANNER([RPM debugedit])
AT_TESTED([debugedit])
# Helper to create some test binaries.
-# Optional parameter can specify additional gcc parameters.
-m4_define([RPM_DEBUGEDIT_SETUP],[[
+# Optional first parameter can specify alternative compiler than [gcc].
+# Optional second parameter can specify additional compiler parameters.
+m4_define([RPM_DEBUGEDIT_SETUP],[
# Create some test binaries. Create and build them in different subdirs
# to make sure they produce different relative/absolute paths.
@@ -37,11 +38,11 @@ cp "${abs_srcdir}"/data/SOURCES/foobar.h subdir_headers
cp "${abs_srcdir}"/data/SOURCES/baz.c .
# First three object files (foo.o subdir_bar/bar.o and baz.o)
-gcc -g3 -Isubdir_headers $1 -c subdir_foo/foo.c
+m4_if($1,,gcc,$1) -g3 -Isubdir_headers -c $2 subdir_foo/foo.c
cd subdir_bar
-gcc -g3 -I../subdir_headers $1 -c bar.c
+m4_if($1,,gcc,$1) -g3 -I../subdir_headers -c $2 bar.c
cd ..
-gcc -g3 -I$(pwd)/subdir_headers $1 -c $(pwd)/baz.c
+m4_if($1,,gcc,$1) -g3 -I$(pwd)/subdir_headers -c $2 $(pwd)/baz.c
# Then a partially linked object file (somewhat like a kernel module).
# This will still have relocations between the debug sections.
@@ -49,8 +50,8 @@ ld -r -o foobarbaz.part.o foo.o subdir_bar/bar.o baz.o
# Create an executable. Relocations between debug sections will
# have been resolved.
-gcc -g3 -o foobarbaz.exe foo.o subdir_bar/bar.o baz.o
-]])
+m4_if($1,,gcc,$1) -g3 -o foobarbaz.exe foo.o subdir_bar/bar.o baz.o
+])
# ===
# Check debugedit --help doesn't crash and burn.
@@ -254,7 +255,7 @@ AT_CLEANUP
# Make sure -fdebug-types-section has updated strings in objects.
# ===
m4_define([RPM_DEBUGEDIT_DEBUG_TYPES_OBJECTS],[
-RPM_DEBUGEDIT_SETUP($1)
+RPM_DEBUGEDIT_SETUP($1,$2)
AT_DATA([expout],
[st1
@@ -274,21 +275,28 @@ stz
AT_CHECK([[debugedit -b $(pwd) -d /foo/bar/baz ./foo.o]])
AT_CHECK([[debugedit -b $(pwd) -d /foo/bar/baz ./subdir_bar/bar.o]])
AT_CHECK([[debugedit -b $(pwd) -d /foo/bar/baz ./baz.o]])
-AT_CHECK([[
+AT_CHECK([
for i in ./foo.o ./subdir_bar/bar.o ./baz.o;do \
+m4_if($1,gcc,[[ \
readelf --debug-dump=info $i \
| awk '/Abbrev Number:.*DW_TAG_type_unit/{p=1}{if(p)print}/^$/{p=0}'
\
| sed -n 's/^.*> *DW_AT_name *:.* \(stringp[^ ]*\|st.\)$/\1/p' \
| sort;
+]],[[ \
+ llvm-dwarfdump $i \
+ | awk '/^0x[0-9a-f]*: [^ ]* Unit:/{p=0}/^0x[0-9a-f]*: Type
Unit:/{p=1}{if(p)print}' \
+ | sed -n 's/^ *DW_AT_name\t("\(stringp[^ ]*\|st.\)")$/\1/p' \
+ | sort;
+]]) \
done
-]],[0],[expout])
+],[0],[expout])
])
# ===
# Make sure -fdebug-types-section has updated strings in partial linked object.
# ===
m4_define([RPM_DEBUGEDIT_DEBUG_TYPES_PARTIAL],[
-RPM_DEBUGEDIT_SETUP($1)
+RPM_DEBUGEDIT_SETUP($1,$2)
AT_DATA([expout],
[st1
@@ -302,19 +310,26 @@ stz
])
AT_CHECK([[debugedit -b $(pwd) -d /foo/bar/baz ./foobarbaz.part.o]])
-AT_CHECK([[
+AT_CHECK([
+m4_if($1,gcc,[[
readelf --debug-dump=info ./foobarbaz.part.o \
| awk '/Abbrev Number:.*DW_TAG_type_unit/{p=1}{if(p)print}/^$/{p=0}' \
| sed -n 's/^.*> *DW_AT_name *:.* \(stringp[^ ]*\|st.\)$/\1/p' \
| sort
-]],[0],[expout])
+]],[[
+ llvm-dwarfdump ./foobarbaz.part.o \
+| awk '/^0x[0-9a-f]*: [^ ]* Unit:/{p=0}/^0x[0-9a-f]*: Type
Unit:/{p=1}{if(p)print}' \
+| sed -n 's/^ *DW_AT_name\t("\(stringp[^ ]*\|st.\)")$/\1/p' \
+| sort
+]])
+],[0],[expout])
])
# ===
# Make sure -fdebug-types-section has updated strings in executable.
# ===
m4_define([RPM_DEBUGEDIT_DEBUG_TYPES_EXE],[
-RPM_DEBUGEDIT_SETUP($1)
+RPM_DEBUGEDIT_SETUP($1,$2)
AT_DATA([expout],
[st1
@@ -328,42 +343,67 @@ stz
])
AT_CHECK([[debugedit -b $(pwd) -d /foo/bar/baz ./foobarbaz.exe]])
-AT_CHECK([[
+AT_CHECK([
+m4_if($1,gcc,[[
readelf --debug-dump=info ./foobarbaz.exe \
| awk '/Abbrev Number:.*DW_TAG_type_unit/{p=1}{if(p)print}/^$/{p=0}' \
| sed -n 's/^.*> *DW_AT_name *:.* \(stringp[^ ]*\|st.\)$/\1/p' \
| sort
-]],[0],[expout])
+]],[[
+ llvm-dwarfdump ./foobarbaz.exe \
+| awk '/^0x[0-9a-f]*: [^ ]* Unit:/{p=0}/^0x[0-9a-f]*: Type
Unit:/{p=1}{if(p)print}' \
+| sed -n 's/^ *DW_AT_name\t("\(stringp[^ ]*\|st.\)")$/\1/p' \
+| sort
+]])
+],[0],[expout])
])
-AT_SETUP([debugedit DWARF-4 .debug_types objects])
+AT_SETUP([debugedit gcc DWARF-4 .debug_types objects])
+AT_KEYWORDS([debugtypes] [debugedit])
+RPM_DEBUGEDIT_DEBUG_TYPES_OBJECTS([gcc],[-gdwarf-4 -fdebug-types-section])
+AT_CLEANUP
+
+AT_SETUP([debugedit gcc DWARF-4 .debug_types partial])
AT_KEYWORDS([debugtypes]
[Rpm-maint] [PATCH 4/5] debugedit: Implement DWARF-5 .debug_types (in .debug_info).
diff --git a/tests/debugedit.at b/tests/debugedit.at
index 49721a342..bcd86ac67 100644
--- a/tests/debugedit.at
+++ b/tests/debugedit.at
@@ -253,9 +253,8 @@ AT_CLEANUP
# ===
# Make sure -fdebug-types-section has updated strings in objects.
# ===
-AT_SETUP([debugedit .debug_types objects])
-AT_KEYWORDS([debugtypes] [debugedit])
-RPM_DEBUGEDIT_SETUP([-fdebug-types-section])
+m4_define([RPM_DEBUGEDIT_DEBUG_TYPES_OBJECTS],[
+RPM_DEBUGEDIT_SETUP($1)
AT_DATA([expout],
[st1
@@ -283,15 +282,13 @@ for i in ./foo.o ./subdir_bar/bar.o ./baz.o;do \
| sort;
done
]],[0],[expout])
-
-AT_CLEANUP
+])
# ===
# Make sure -fdebug-types-section has updated strings in partial linked object.
# ===
-AT_SETUP([debugedit .debug_types partial])
-AT_KEYWORDS([debugtypes] [debugedit])
-RPM_DEBUGEDIT_SETUP([-fdebug-types-section])
+m4_define([RPM_DEBUGEDIT_DEBUG_TYPES_PARTIAL],[
+RPM_DEBUGEDIT_SETUP($1)
AT_DATA([expout],
[st1
@@ -311,15 +308,13 @@ readelf --debug-dump=info ./foobarbaz.part.o \
| sed -n 's/^.*> *DW_AT_name *:.* \(stringp[^ ]*\|st.\)$/\1/p' \
| sort
]],[0],[expout])
-
-AT_CLEANUP
+])
# ===
# Make sure -fdebug-types-section has updated strings in executable.
# ===
-AT_SETUP([debugedit .debug_types exe])
-AT_KEYWORDS([debugtypes] [debugedit])
-RPM_DEBUGEDIT_SETUP([-fdebug-types-section])
+m4_define([RPM_DEBUGEDIT_DEBUG_TYPES_EXE],[
+RPM_DEBUGEDIT_SETUP($1)
AT_DATA([expout],
[st1
@@ -339,7 +334,36 @@ readelf --debug-dump=info ./foobarbaz.exe \
| sed -n 's/^.*> *DW_AT_name *:.* \(stringp[^ ]*\|st.\)$/\1/p' \
| sort
]],[0],[expout])
+])
+
+AT_SETUP([debugedit DWARF-4 .debug_types objects])
+AT_KEYWORDS([debugtypes] [debugedit])
+RPM_DEBUGEDIT_DEBUG_TYPES_OBJECTS([-gdwarf-4 -fdebug-types-section])
+AT_CLEANUP
+AT_SETUP([debugedit DWARF-4 .debug_types partial])
+AT_KEYWORDS([debugtypes] [debugedit])
+RPM_DEBUGEDIT_DEBUG_TYPES_PARTIAL([-gdwarf-4 -fdebug-types-section])
+AT_CLEANUP
+
+AT_SETUP([debugedit DWARF-4 .debug_types exe])
+AT_KEYWORDS([debugtypes] [debugedit])
+RPM_DEBUGEDIT_DEBUG_TYPES_EXE([-gdwarf-4 -fdebug-types-section])
+AT_CLEANUP
+
+AT_SETUP([debugedit DWARF-5 .debug_types objects])
+AT_KEYWORDS([debugtypes] [debugedit])
+RPM_DEBUGEDIT_DEBUG_TYPES_OBJECTS([-gdwarf-5 -fdebug-types-section])
+AT_CLEANUP
+
+AT_SETUP([debugedit DWARF-5 .debug_types partial])
+AT_KEYWORDS([debugtypes] [debugedit])
+RPM_DEBUGEDIT_DEBUG_TYPES_PARTIAL([-gdwarf-5 -fdebug-types-section])
+AT_CLEANUP
+
+AT_SETUP([debugedit DWARF-5 .debug_types exe])
+AT_KEYWORDS([debugtypes] [debugedit])
+RPM_DEBUGEDIT_DEBUG_TYPES_EXE([-gdwarf-5 -fdebug-types-section])
AT_CLEANUP
# foo.o and bar.o are build with relative paths and so will use the
diff --git a/tools/debugedit.c b/tools/debugedit.c
index 9f1dc2d3f..19f69e263 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -433,7 +433,8 @@ typedef struct debug_section
int sec, relsec;
REL *relbuf;
REL *relend;
-/* Only happens for COMDAT .debug_macro and .debug_types. */
+/* Only happens for COMDAT .debug_macro, .debug_types and DWARF-5
+ .debug_info. */
struct debug_section *next;
} debug_section;
@@ -755,12 +756,19 @@ no_memory:
}
form = read_uleb128 (ptr);
if (form == 2
- || (form > DW_FORM_flag_present && form != DW_FORM_ref_sig8))
+ || (form > DW_FORM_flag_present && form != DW_FORM_ref_sig8
+ && form != DW_FORM_implicit_const))
{
- error (0, 0, "%s: Unknown DWARF DW_FORM_%d", dso->filename, form);
+ error (0, 0, "%s: Unknown DWARF abbrev DW_FORM_0x%x",
+dso->filename, form);
htab_delete (h);
return NULL;
}
+ if (form == DW_FORM_implicit_const)
+ {
+ /* It is SLEB128 but the value is dropped anyway. */
+ read_uleb128 (ptr);
+ }
t->attr[t->nattr].attr = attr;
t->attr[t->nattr++].form = form;
@@ -1505,6 +1513,7 @@ skip_form (DSO *dso, uint32_t *formp, unsigned char
**ptrp)
*ptrp += 4;
break;
case DW_FORM_flag_present:
+case DW_FORM_implicit_const:
break;
case DW_FORM_addr:
*ptrp += ptr_size;
@@ -2018,7 +2027,7 @@ line_rel_cmp (const void *a, const void *b)
}
static int
-edit_info (DSO *dso, int phase, struct debug_section *sec)
+edit_info (DSO *dso, int phase, struct debug_section *sec, bool is_types)
{
unsigned char *ptr, *endcu, *endsec;
uint32_t value;
@@ -2033,7 +2042,9 @@ edit_info (DSO *dso, int phase, struct debug_section *sec)
endsec = ptr + sec->size;
while (ptr < endsec)
{
- if (ptr + (sec == _sections[DEBUG_INFO] ? 11 : 23) > endsec)
+ unsigned char *sec_start = ptr;
+
+ if (ptr + 4 + 2 + 1 + 1 > endsec)
{
error (0, 0, "%s: %s CU header too small",
dso->filename, sec->name);
@@ -2055,13 +2066,48 @@ edit_info (DSO
[Rpm-maint] [PATCH 1/5] [NFC] debugedit: Protect macro arguments by parentheses
diff --git a/tools/debugedit.c b/tools/debugedit.c
index c2884933c..8e85847d1 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -233,7 +233,7 @@ typedef struct
int shift = 0; \
do \
{ \
- c = *ptr++; \
+ c = *(ptr)++;\
ret |= (c & 0x7f) << shift; \
shift += 7; \
} while (c & 0x80);\
@@ -251,7 +251,7 @@ typedef struct
valv >>= 7; \
if (valv)\
c |= 0x80; \
- *ptr++ = c; \
+ *(ptr)++ = c;\
} \
while (valv);\
})
@@ -311,7 +311,7 @@ strptr (DSO *dso, int sec, off_t offset)
}
-#define read_8(ptr) *ptr++
+#define read_8(ptr) *(ptr)++
#define read_16(ptr) ({\
uint16_t ret = do_read_16 (ptr); \
@@ -328,13 +328,13 @@ strptr (DSO *dso, int sec, off_t offset)
REL *relptr, *relend;
int reltype;
-#define do_read_32_relocated(ptr) ({ \
- uint32_t dret = do_read_32 (ptr);\
+#define do_read_32_relocated(xptr) ({ \
+ uint32_t dret = do_read_32 (xptr); \
if (relptr) \
{ \
- while (relptr < relend && relptr->ptr < ptr) \
+ while (relptr < relend && relptr->ptr < (xptr)) \
++relptr; \
- if (relptr < relend && relptr->ptr == ptr) \
+ if (relptr < relend && relptr->ptr == (xptr))\
{ \
if (reltype == SHT_REL) \
dret += relptr->addend; \
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH 3/5] [NFC] debugedit: Move code to separate functions.
To be used by next DWARF-5 patch.
diff --git a/tools/debugedit.c b/tools/debugedit.c
index ff72759ca..9f1dc2d3f 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -1457,37 +1457,128 @@ edit_dwarf2_line (DSO *dso)
}
}
-/* Called during phase zero for each debug_line table referenced from
- .debug_info. Outputs all source files seen and records any
- adjustments needed in the debug_list data structures. Returns true
- if line_table needs to be rewrite either the dir or file paths. */
+/* Record or adjust (according to phase) DW_FORM_strp. */
+static void
+edit_strp (DSO *dso, unsigned char *ptr, int phase, bool handled_strp)
+{
+ unsigned char *ptr_orig = ptr;
+
+ /* In the first pass we collect all strings, in the
+ second we put the new references back (if there are
+ any changes). */
+ if (phase == 0)
+{
+ /* handled_strp is set for attributes referring to
+files. If it is set the string is already
+recorded. */
+ if (! handled_strp)
+ {
+ size_t idx = do_read_32_relocated (ptr);
+ record_existing_string_entry_idx (>strings, idx);
+ }
+}
+ else if (need_strp_update) /* && phase == 1 */
+{
+ struct stridxentry *entry;
+ size_t idx, new_idx;
+ idx = do_read_32_relocated (ptr);
+ entry = string_find_entry (>strings, idx);
+ new_idx = strent_offset (entry->entry);
+ do_write_32_relocated (ptr, new_idx);
+}
+
+ assert (ptr == ptr_orig);
+}
+
+/* Adjust *PTRP after the current *FORMP, update *FORMP for FORM_INDIRECT. */
+static enum { FORM_OK, FORM_ERROR, FORM_INDIRECT }
+skip_form (DSO *dso, uint32_t *formp, unsigned char **ptrp)
+{
+ size_t len = 0;
+
+ switch (*formp)
+{
+case DW_FORM_ref_addr:
+ if (cu_version == 2)
+ *ptrp += ptr_size;
+ else
+ *ptrp += 4;
+ break;
+case DW_FORM_flag_present:
+ break;
+case DW_FORM_addr:
+ *ptrp += ptr_size;
+ break;
+case DW_FORM_ref1:
+case DW_FORM_flag:
+case DW_FORM_data1:
+ ++*ptrp;
+ break;
+case DW_FORM_ref2:
+case DW_FORM_data2:
+ *ptrp += 2;
+ break;
+case DW_FORM_ref4:
+case DW_FORM_data4:
+case DW_FORM_sec_offset:
+ *ptrp += 4;
+ break;
+case DW_FORM_ref8:
+case DW_FORM_data8:
+case DW_FORM_ref_sig8:
+ *ptrp += 8;
+ break;
+case DW_FORM_sdata:
+case DW_FORM_ref_udata:
+case DW_FORM_udata:
+ read_uleb128 (*ptrp);
+ break;
+case DW_FORM_strp:
+ *ptrp += 4;
+ break;
+case DW_FORM_string:
+ *ptrp = (unsigned char *) strchr ((char *)*ptrp, '\0') + 1;
+ break;
+case DW_FORM_indirect:
+ *formp = read_uleb128 (*ptrp);
+ return FORM_INDIRECT;
+case DW_FORM_block1:
+ len = *(*ptrp)++;
+ break;
+case DW_FORM_block2:
+ len = read_16 (*ptrp);
+ *formp = DW_FORM_block1;
+ break;
+case DW_FORM_block4:
+ len = read_32 (*ptrp);
+ *formp = DW_FORM_block1;
+ break;
+case DW_FORM_block:
+case DW_FORM_exprloc:
+ len = read_uleb128 (*ptrp);
+ *formp = DW_FORM_block1;
+ assert (len < UINT_MAX);
+ break;
+default:
+ error (0, 0, "%s: Unknown DWARF DW_FORM_%d", dso->filename, *formp);
+ return FORM_ERROR;
+}
+
+ if (*formp == DW_FORM_block1)
+*ptrp += len;
+
+ return FORM_OK;
+}
+
+/* Part of read_dwarf2_line processing DWARF-4. */
static bool
-read_dwarf2_line (DSO *dso, uint32_t off, char *comp_dir)
+read_dwarf4_line (DSO *dso, unsigned char *ptr, char *comp_dir,
+ struct line_table *table)
{
- unsigned char *ptr, *dir;
unsigned char **dirt;
uint32_t value, dirt_cnt;
size_t comp_dir_len = !comp_dir ? 0 : strlen (comp_dir);
- struct line_table *table;
-
- if (get_line_table (dso, off, ) == false
- || table == NULL)
-return false;
-
- /* Skip to the directory table. The rest of the header has already
- been read and checked by get_line_table. */
- ptr = debug_sections[DEBUG_LINE].data + off;
- ptr += (4 /* unit len */
- + 2 /* version */
- + 4 /* header len */
- + 1 /* min instr len */
- + (table->version >= 4) /* max op per instr, if version >= 4 */
- + 1 /* default is stmt */
- + 1 /* line base */
- + 1 /* line range */
- + 1 /* opcode base */
- + table->opcode_base - 1); /* opcode len table */
- dir = ptr;
+ unsigned char *dir = ptr;
/* dir table: */
value = 1;
@@ -1620,6 +1711,40 @@ read_dwarf2_line (DSO *dso, uint32_t off, char *comp_dir)
read_uleb128 (ptr);
}
+ return true;
+}
+
+/* Called during phase zero for each debug_line table referenced from
+ .debug_info. Outputs all source files seen and records any
+ adjustments needed in the debug_list data structures. Returns true
+ if line_table needs to be rewrite either the dir or file paths. */
+static bool
+read_dwarf2_line (DSO *dso,
[Rpm-maint] [PATCH 2/5] debugedit: Fix handling in caller for errors in called read_dwarf2_line.
diff --git a/tools/debugedit.c b/tools/debugedit.c
index 8e85847d1..ff72759ca 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -1155,7 +1155,7 @@ get_line_table (DSO *dso, size_t off, struct line_table
**table)
if (lines->table[i].old_idx == off)
{
*table = >table[i];
- return false;
+ return true;
}
if (lines->size == lines->used)
@@ -1621,7 +1621,8 @@ read_dwarf2_line (DSO *dso, uint32_t off, char *comp_dir)
}
dso->lines.debug_lines_len += 4 + table->unit_length + table->size_diff;
- return table->replace_dirs || table->replace_files;
+ need_stmt_update = table->replace_dirs || table->replace_files;
+ return true;
}
/* Called during phase one, after the table has been sorted. */
@@ -1939,9 +1940,11 @@ edit_attributes (DSO *dso, unsigned char *ptr, struct
abbrev_tag *t, int phase)
that). Note that calculating the new size and offsets is done
separately (at the end of phase zero after all CUs have been
scanned in dwarf2_edit). */
- if (phase == 0 && found_list_offs
- && read_dwarf2_line (dso, list_offs, comp_dir))
-need_stmt_update = true;
+ if (found_list_offs && ! read_dwarf2_line (dso, list_offs, comp_dir))
+{
+ free (comp_dir);
+ return NULL;
+}
free (comp_dir);
@@ -2059,7 +2062,10 @@ edit_info (DSO *dso, int phase, struct debug_section
*sec)
ptr = edit_attributes (dso, ptr, t, phase);
if (ptr == NULL)
- break;
+ {
+ htab_delete (abbrev);
+ return 1;
+ }
}
htab_delete (abbrev);
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove support for redundant %_filter_GLIBC_PRIVATE mechanism (#1333)
@Conan-Kudo approved this pull request. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1333#pullrequestreview-469937196___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
Making everything configurable is not such a hot idea, really. Making the shell macro configurable means you open up the possibility of anybody screwing up the core macro primitive. %() equals popen() which means system shell, whatever that is, and I believe that should be left alone. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675866905___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
