Re: [PATCH 0/4] Add AARCH64 pointer authentication support
Hi Mark, thanks for looking, and sorry for the delay On 28/04/2022 20:56, Mark Wielaard wrote: > Hi German, > > On Mon, Apr 25, 2022 at 02:03:07PM +, German Gomez via Elfutils-devel > wrote: >> I've included a set of patches in order to demangle return addresses in >> aarch64 platforms with pointer authentication. >> >> Besides adding the implementation of the negate_ra_state opcode, there >> is a new function in the libdwfl.h header to feed the PAC masks to the >> library. >> >> Let me know if there are any concerns with the current version. > Thanks a lot for this. Last time I looked at this didn't have any > means to test this, so I skipped implementing it. How did you test? Do > distributions now enable PAC by default and is there hardware (qemu?) > support? So far I've been testing on Graviton3 cores (running linux), which seem to implement the PAC extension, and it came enabled by default. https://www.kernel.org/doc/html/latest/arm64/pointer-authentication.html > I haven't been able to look at the actual patches yet. And I am on > vacation this week. But I'll review next week after I am back. Thanks a lot for looking. > > A quick scan shows we need a aarch64 special public function, which > would be slightly ugly imho. I had hoped it could be a variant of the > func_addr_mask. But maybe this is too different to make more generic. I did consider func_addr_mask initially, but when I wrote the patch it wasn't exposed as a perf-thread value. Currently PAC masks are constant but might be different from thread to thread in the future. So I placed it in the Thread struct. I agree the arch-specific naming is not pretty. I think I can certainly rework it into a more generic feature. But I think I would need to make sure that the masks can be supplied to the Thread struct before the unwind. Thanks, German > Cheers, > > Mark >
Re: [PATCH 0/4] Add AARCH64 pointer authentication support
On 19/05/2022 14:30, German Gomez via Elfutils-devel wrote: > Hi Mark, thanks for looking, and sorry for the delay > > On 28/04/2022 20:56, Mark Wielaard wrote: >> Hi German, >> >> On Mon, Apr 25, 2022 at 02:03:07PM +, German Gomez via Elfutils-devel >> wrote: >>> [...] >> Thanks a lot for this. Last time I looked at this didn't have any >> means to test this, so I skipped implementing it. How did you test? Do >> distributions now enable PAC by default and is there hardware (qemu?) >> support? > So far I've been testing on Graviton3 cores (running linux), which seem > to implement the PAC extension, and it came enabled by default. > Regarding qemu support, I haven't used it myself so I can't really speak for it, but according to the docs FEAT_PAuth is supported. https://www.qemu.org/docs/master/system/arm/emulation.html
[Bug general/29158] New: 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 Bug ID: 29158 Summary: 0.187 fails to build with gcc-10: #error "Please include config.h first." Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: yuri at tsoft dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- In file included from color.c:34: /usr/local/share/gnulib/lib/argp.h:583:3: error: #error "Please include config.h first." 583 | #error "Please include config.h first." | ^ /usr/local/share/gnulib/lib/argp.h:585:1: error: unknown type name '_GL_INLINE_HEADER_BEGIN' 585 | _GL_INLINE_HEADER_BEGIN | ^~~ /usr/local/share/gnulib/lib/argp.h:616:9: error: expected ';' before 'void' 616 | ARGP_EI void | ^~~~ /usr/local/share/gnulib/lib/argp.h:622:9: error: expected ';' before 'int' 622 | ARGP_EI int | ^~~ /usr/local/share/gnulib/lib/argp.h:634:9: error: expected ';' before 'int' 634 | ARGP_EI int | ^~~ /usr/local/share/gnulib/lib/argp.h:645:22: error: expected ';' before 'struct' 645 | _GL_INLINE_HEADER_END | ^ | ; OS: FreeBSD 13 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] readelf: Support --dynamic with --use-dynamic
Hi,
On Thu, May 05, 2022 at 09:01:24PM +0800, Di Chen via Elfutils-devel wrote:
> From 3ac23c2584d76114deab0c0af6f4af99068dc7f4 Mon Sep 17 00:00:00 2001
> From: Di Chen
> Date: Thu, 28 Apr 2022 19:55:33 +0800
> Subject: [PATCH] readelf: Support --dynamic with --use-dynamic
>
> Currently, eu-readelf is using section headers to dump the dynamic
> segment information (print_dynamic -> handle_dynamic).
>
> This patch adds new options to eu-readelf (-D, --use-dynamic)
> for (-d, --dynamic).
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=28873
This looks pretty good. But there are lots of white-space issues which
make it hard to apply the patch. Could you sent it again preferrably
using git send-email ?
> Signed-off-by: Di Chen
> ---
> src/readelf.c | 168 +---
> tests/Makefile.am | 3 +-
> tests/run-readelf-Dd.sh | 65
> 3 files changed, 223 insertions(+), 13 deletions(-)
> create mode 100755 tests/run-readelf-Dd.sh
>
> diff --git a/src/readelf.c b/src/readelf.c
> index 4b6aab2b..e578456b 100644
> --- a/src/readelf.c
> +++ b/src/readelf.c
> @@ -137,6 +137,8 @@ static const struct argp_option options[] =
>{ "string-dump", 'p', NULL, OPTION_ALIAS | OPTION_HIDDEN, NULL, 0 },
>{ "archive-index", 'c', NULL, 0,
> N_("Display the symbol index of an archive"), 0 },
> + { "use-dynamic", 'D', NULL, 0,
> +N_("Use the dynamic section info when displaying symbols"), 0 },
This doesn't handle symbols yet. Should it simply say:
"Use the dynamic segment when possible for displaying info"
>{ NULL, 0, NULL, 0, N_("Output control:"), 0 },
>{ "numeric-addresses", 'N', NULL, 0,
> @@ -195,6 +197,9 @@ static bool print_symbol_table;
> /* True if (only) the dynsym table should be printed. */
> static bool print_dynsym_table;
>
> +/* True if reconstruct dynamic symbol table from the PT_DYNAMIC segment.
> */
> +static bool use_dynamic_segment;
> +
> /* A specific section name, or NULL to print all symbol tables. */
> static char *symbol_table_section;
>
> @@ -268,6 +273,19 @@ static enum section_e
> | section_macro | section_addr | section_types)
> } print_debug_sections, implicit_debug_sections;
>
> +enum dyn_idx
> +{
> + i_strsz,
> + i_verneed,
> + i_verdef,
> + i_versym,
> + i_symtab,
> + i_strtab,
> + i_hash,
> + i_gnu_hash,
> + i_max
> +};
Maybe move this just before it is used in declarations of the
get_dyn... functions?
> /* Select hex dumping of sections. */
> static struct section_argument *dump_data_sections;
> static struct section_argument **dump_data_sections_tail =
> &dump_data_sections;
> @@ -318,6 +336,11 @@ static void dump_strings (Ebl *ebl);
> static void print_strings (Ebl *ebl);
> static void dump_archive_index (Elf *, const char *);
>
> +/* Declarations of local functions for use-dynamic. */
> +static Elf_Data * get_dynscn_strtab(Elf *elf, GElf_Phdr *phdr);
> +static void get_dynscn_addrs(Elf *elf, GElf_Phdr *phdr, GElf_Addr
> addrs[i_max]);
> +static void find_offsets(Elf *elf, GElf_Addr main_bias, size_t n,
> +GElf_Addr addrs[n], GElf_Off offs[n]);
I mean, just before these.
> /* Looked up once with gettext in main. */
> static char *yes_str;
> @@ -429,6 +452,9 @@ parse_opt (int key, char *arg,
>print_dynamic_table = true;
>any_control_option = true;
>break;
> +case 'D':
> + use_dynamic_segment = true;
> + break;
> case 'e':
>print_debug_sections |= section_exception;
>any_control_option = true;
> @@ -1791,7 +1817,7 @@ get_dyn_ents (Elf_Data * dyn_data)
OK, setting flag.
>
> static void
> -handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr *shdr)
> +handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr *shdr, GElf_Phdr *phdr)
> {
>int class = gelf_getclass (ebl->elf);
>GElf_Shdr glink_mem;
> @@ -1802,13 +1828,20 @@ handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr
> *shdr)
>size_t dyn_ents;
>
>/* Get the data of the section. */
> - data = elf_getdata (scn, NULL);
> + if (use_dynamic_segment)
> +data = elf_getdata_rawchunk(
> + ebl->elf, phdr->p_offset, phdr->p_filesz, ELF_T_DYN);
> + else
> +data = elf_getdata (scn, NULL);
> +
>if (data == NULL)
> return;
>
>/* Get the dynamic section entry number */
>dyn_ents = get_dyn_ents (data);
>
> + if (!use_dynamic_segment)
> +{
>/* Get the section header string table index. */
>if (unlikely (elf_getshdrstrndx (ebl->elf, &shstrndx) < 0))
> error_exit (0, _("cannot get section header string table index"));
> @@ -1828,8 +1861,25 @@ handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr
> *shdr)
>shdr->sh_offset,
>(int) shdr->sh_link,
>elf_strptr (ebl->elf, shstrndx, glink->sh_name));
> +} else {
> + printf (ngettext ("\
> +\nDynamic segment contains %lu entry:\n Addr: %#0*" PRIx64 " Offset:
> %#08" PRIx64 "\n",
> +"\
> +\nDynamic segment contains %lu entries:\n Addr: %#0*" PRI
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Normally glibc provides argp. I think this means you integrated gnulib argp incorrectly. How do you configure and what does config.log say about argp? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 --- Comment #2 from yuri at tsoft dot com --- configure arguments: > --program-prefix=eu- --disable-debuginfod --enable-nls --prefix=/usr/local configure output: > checking for library containing argp_parse... none required config.log file: https://people.freebsd.org/~yuri/elfutils-config.log -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 --- Comment #3 from yuri at tsoft dot com --- Also: * the problem only exists with gcc, and not with clang-12. * 0.179 didn't have such problem, so this is a regression. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 --- Comment #4 from Mark Wielaard --- You might want to ask someone who knows about how freebsd provides argp to see if they understand why your CFLAGS seem to contain -I/usr/local/share/gnulib/lib and your LDFLAGS contain /usr/local/lib/libargp.so. That seems to confuse the build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 --- Comment #5 from yuri at tsoft dot com --- The port adds -I/usr/local/share/gnulib/lib and LDFLAGS=/usr/local/lib/libargp.so - otherwise it doesn't find argp. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 --- Comment #6 from Mark Wielaard --- Sorry you have to ask whoever added -I/usr/local/share/gnulib/lib to CFLAGS how that is supposed to work. Obviously the argp.h header found there isn't usable as is. Normally people build against glibc or argp-standalone. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 --- Comment #7 from yuri at tsoft dot com --- (In reply to Mark Wielaard from comment #6) > Sorry you have to ask whoever added -I/usr/local/share/gnulib/lib to CFLAGS > how that is supposed to work. Obviously the argp.h header found there isn't > usable as is. Normally people build against glibc or argp-standalone. I added these flags to solve build failures. This works when built with clang. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29158] 0.187 fails to build with gcc-10: #error "Please include config.h first."
https://sourceware.org/bugzilla/show_bug.cgi?id=29158 --- Comment #8 from yuri at tsoft dot com --- It might be that clang-built and gcc-built code is just compatible. Not sure if this is the case here. -- You are receiving this mail because: You are on the CC list for the bug.
