[PATCH] strip: Deal with ARM data marker symbols pointing to debug sections.

[Mark Wielaard]

ARM data marker symbols "$d" indicate the start of a sequence of data
items in a section. For data only sections no data marker symbol is
necessary, but may be put pointing to the start of the section.
binutils however has a bug which places a data marker symbol somewhere
inside the section (at least for .debug_frame).
https://sourceware.org/bugzilla/show_bug.cgi?id=21809

When strip finds a symbol pointing to a debug section that would be
put into the .debug file then it will copy over the whole symbol table.
This isn't necessary because the symbol is redundant.

Add an ebl hook to recognize data marker symbols with implementations
for arm and aarch64. Use it in strip to strip such symbols from the
symbol table if they point to a debug section.

Signed-off-by: Mark Wielaard 
---
 backends/ChangeLog  |   7 +++
 backends/aarch64_init.c |   3 +-
 backends/aarch64_symbol.c   |  14 +-
 backends/arm_init.c |   3 +-
 backends/arm_symbol.c   |  15 +-
 libebl/ChangeLog|   9 
 libebl/Makefile.am  |   5 +-
 libebl/ebl-hooks.h  |   5 +-
 libebl/ebl_data_marker_symbol.c |  44 +
 libebl/eblopenbackend.c |  11 -
 libebl/libebl.h |   6 ++-
 src/ChangeLog   |   5 ++
 src/strip.c |  30 +---
 tests/ChangeLog |   6 +++
 tests/Makefile.am   |   4 +-
 tests/run-strip-g.sh| 102 
 16 files changed, 252 insertions(+), 17 deletions(-)
 create mode 100644 libebl/ebl_data_marker_symbol.c
 create mode 100755 tests/run-strip-g.sh

diff --git a/backends/ChangeLog b/backends/ChangeLog
index d628245..6055860 100644
--- a/backends/ChangeLog
+++ b/backends/ChangeLog
@@ -1,3 +1,10 @@
+2017-08-20  Mark Wielaard  
+
+   * aarch64_init.c (aarch64_init): Hook data_marker_symbol.
+   * aarch64_symbol.c (aarch64_data_marker_symbol): New function.
+   * arm_init.c (arm_init): Hook data_marker_symbol.
+   * arm_symbol.c (aarch64_data_marker_symbol): New function.
+
 2017-06-17  Mark Wielaard  
 
* s390_initreg.c: Swap sys/ptrace.h and asm/ptrace.h include order.
diff --git a/backends/aarch64_init.c b/backends/aarch64_init.c
index 0866494..fad923f 100644
--- a/backends/aarch64_init.c
+++ b/backends/aarch64_init.c
@@ -1,5 +1,5 @@
 /* Initialization of AArch64 specific backend library.
-   Copyright (C) 2013 Red Hat, Inc.
+   Copyright (C) 2013, 2017 Red Hat, Inc.
This file is part of elfutils.
 
This file is free software; you can redistribute it and/or modify
@@ -56,6 +56,7 @@ aarch64_init (Elf *elf __attribute__ ((unused)),
   HOOK (eh, reloc_simple_type);
   HOOK (eh, return_value_location);
   HOOK (eh, check_special_symbol);
+  HOOK (eh, data_marker_symbol);
   HOOK (eh, abi_cfi);
 
   /* X0-X30 (31 regs) + SP + 1 Reserved + ELR, 30 Reserved regs (34-43)
diff --git a/backends/aarch64_symbol.c b/backends/aarch64_symbol.c
index 76999e4..da3382e 100644
--- a/backends/aarch64_symbol.c
+++ b/backends/aarch64_symbol.c
@@ -1,5 +1,5 @@
 /* AArch64 specific symbolic name handling.
-   Copyright (C) 2013, 2015 Red Hat, Inc.
+   Copyright (C) 2013, 2015, 2017 Red Hat, Inc.
This file is part of elfutils.
 
This file is free software; you can redistribute it and/or modify
@@ -90,3 +90,15 @@ aarch64_check_special_symbol (Elf *elf, GElf_Ehdr *ehdr, 
const GElf_Sym *sym,
 
   return false;
 }
+
+/* A data mapping symbol is a symbol with "$d" name or "$d." name,
+   STT_NOTYPE, STB_LOCAL and st_size of zero. The indicate the stat of a
+   sequence of data items.  */
+bool
+aarch64_data_marker_symbol (const GElf_Sym *sym, const char *sname)
+{
+  return (sym != NULL && sname != NULL
+ && sym->st_size == 0 && GELF_ST_BIND (sym->st_info) == STB_LOCAL
+ && GELF_ST_TYPE (sym->st_info) == STT_NOTYPE
+ && (strcmp (sname, "$d") == 0 || strncmp (sname, "$d.", 3) == 0));
+}
diff --git a/backends/arm_init.c b/backends/arm_init.c
index caadac6..f2b1b11 100644
--- a/backends/arm_init.c
+++ b/backends/arm_init.c
@@ -1,5 +1,5 @@
 /* Initialization of Arm specific backend library.
-   Copyright (C) 2002, 2005, 2009, 2013, 2014, 2015 Red Hat, Inc.
+   Copyright (C) 2002, 2005, 2009, 2013, 2014, 2015, 2017 Red Hat, Inc.
This file is part of elfutils.
Written by Ulrich Drepper , 2002.
 
@@ -64,6 +64,7 @@ arm_init (Elf *elf __attribute__ ((unused)),
   HOOK (eh, abi_cfi);
   HOOK (eh, check_reloc_target_type);
   HOOK (eh, symbol_type_name);
+  HOOK (eh, data_marker_symbol);
 
   /* We only unwind the core integer registers.  */
   eh->frame_nregs = 16;
diff --git a/backends/arm_symbol.c b/backends/arm_symbol.c
index da4a50a..3edda72 100644
--- a/backends/arm_symbol.c
+++ b/backends/arm_symbol.c
@@ -1,5 +1,5 @@
 /* Arm specific symbolic name handling.
-   Copyright (C) 2002-2009, 2014, 2015 Red Hat, Inc.
+   Copyright (C) 2002-2009, 2014, 2015, 2017 Re

Re: File index given line (libdw)

[Mark Wielaard]

On Mon, 2017-07-17 at 17:28 +, Sasha Da Rocha Pinheiro wrote:
> I understand your argument. Since I was doing:
>
>dwarf_getsrclines(&cuDIE, &lineBuffer, &lineCount)
>dwarf_getsrcfiles(&cuDIE, &files, &filecount)
> 
> I knew they were related because I used the same DIE. But someone
> trying to use a function which returns only the index could be
> confusing about what Dwarf_Files it came from. 
> 
> But, with
> 
> extern int *
> dwarf_line_files (Dwarf_Line *line, Dwarf_Files **files, size_t *idx);
> 
> they would know what Dwarf_Files the line is related to. For me,
> though, I could pass NULL for files, since I already knew what it is.

I would always double check your assumption that the Dwarf_Files match
with what you expect. And I am still not really convinced storing the
index as a proxy for the actual file name/path associated with a
Dwarf_Line is really a good idea.

But I was working on adding support for DWARF5 .debug_lines and since
files (and directories) can have arbitrary attributes in that version it
makes sense to go from Dwarf_Line to the associated Dwarf_Files/index.
Instead of duplicating the accessor functions (like we now have both
dwarf_filesrc and dwarf_linesrc).

Note that I changed the name to dwarf_line_file. (Dropping the s.)

This does show that we might want to change how we internally store the
Dwarf_Files though. Currently we resolve the whole file path immediately
and don't keep track of the original file name and directory name/path.
You can only get the full file path (through dwarf_filesrc) but not the
associated directory. I am cleaning that up while adding the DWARF5
support. And will add a more generic interface for access file and
directory properties.

Cheers,

Mark
From 84ded5d99cbb20de864ecbca8d0d860510da4234 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Fri, 21 Jul 2017 21:23:07 +0200
Subject: [PATCH] libdw: Add dwarf_line_file.

Signed-off-by: Mark Wielaard 
---
 libdw/ChangeLog |  7 +++
 libdw/Makefile.am   |  2 +-
 libdw/dwarf_line_file.c | 52 +
 libdw/libdw.h   |  5 +
 libdw/libdw.map |  5 +
 tests/ChangeLog |  4 
 tests/get-lines.c   | 23 ++
 7 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 libdw/dwarf_line_file.c

diff --git a/libdw/ChangeLog b/libdw/ChangeLog
index 1e282e4..5d9091a 100644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,3 +1,10 @@
+2017-07-21  Mark Wielaard  
+
+	* dwarf_line_file.c: New file.
+	* Makefile.am (libdw_a_SOURCES): Add dwarf_line_file.c.
+	* libdw.h (dwarf_line_file): New function declaration.
+	* libdw.map (ELFUTILS_0.167): New. Add dwarf_line_file.
+
 2017-04-20  Ulf Hermann  
 
 	* libdw.h: Remove attribute macro declarations and use
diff --git a/libdw/Makefile.am b/libdw/Makefile.am
index 082d96c..bde8856 100644
--- a/libdw/Makefile.am
+++ b/libdw/Makefile.am
@@ -65,7 +65,7 @@ libdw_a_SOURCES = dwarf_begin.c dwarf_begin_elf.c dwarf_end.c dwarf_getelf.c \
 		  dwarf_lineendsequence.c dwarf_lineblock.c \
 		  dwarf_lineprologueend.c dwarf_lineepiloguebegin.c \
 		  dwarf_lineisa.c dwarf_linediscriminator.c \
-		  dwarf_lineop_index.c \
+		  dwarf_lineop_index.c dwarf_line_file.c \
 		  dwarf_onesrcline.c dwarf_formblock.c \
 		  dwarf_getsrcfiles.c dwarf_filesrc.c dwarf_getsrcdirs.c \
 		  dwarf_getlocation.c dwarf_getstring.c dwarf_offabbrev.c \
diff --git a/libdw/dwarf_line_file.c b/libdw/dwarf_line_file.c
new file mode 100644
index 000..e2df642
--- /dev/null
+++ b/libdw/dwarf_line_file.c
@@ -0,0 +1,52 @@
+/* Find line information for address.
+   Copyright (C) 2017 Red Hat, Inc.
+   This file is part of elfutils.
+
+   This file is free software; you can redistribute it and/or modify
+   it under the terms of either
+
+ * the GNU Lesser General Public License as published by the Free
+   Software Foundation; either version 3 of the License, or (at
+   your option) any later version
+
+   or
+
+ * the GNU General Public License as published by the Free
+   Software Foundation; either version 2 of the License, or (at
+   your option) any later version
+
+   or both in parallel, as here.
+
+   elfutils is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see .  */
+
+#ifdef HAVE_CONFIG_H
+# include 
+#endif
+
+#include "libdwP.h"
+
+
+int
+dwarf_line_file (Dwarf_Line *line, Dwarf_Files **files, size_t *idx)
+{
+  if (line == NULL)
+return -1;
+
+  if (line->file >= line->files->nfiles)
+{
+  __libdw_seterrno (DWARF_E_INVALID_DWARF);
+  return -1;
+}
+
+  *

Re: Dwarf_FDE (libdw)

[Mark Wielaard]

On Tue, 2017-07-18 at 16:50 +, Sasha Da Rocha Pinheiro wrote:
> From: Mark Wielaard 
>> The thing is I need to get catch blocks, and eh_frame is not exactly
>> > Dwarf format. That's why I need FDE augmentation data also.
>> > Libdw doesn't do this, am I correct?
>> 
>> libdw handles both .debug_frame and .eh_frame data.
>> And you can use the Dwarf_Frames to unwind.
>> I believe the only thing not directly exposed are the lsda and
>> personality pointers. Is that the functionality that you need for
>> "catch blocks"?
>
> Are you thinking in exposing them?

I am thinking about it. But we don't currently store them. So we would
have reparse them. And since I haven't used them myself I am not sure
what they best way is to expose them. Are you currently using
Dwarf_Frames or Dwarf_CFI_Entry? Could you show some code that uses the
CFI with personality routines and lsda?

Thanks,

Mark

P.S. Please don't top-post. It makes it really hard to see the context.
P.P.S. Please don't add HTML to your postings. The mailinglist will drop
such messages.

Re: FDE augmentation data

[Mark Wielaard]

On Tue, 2017-07-18 at 21:47 +, Sasha Da Rocha Pinheiro wrote:
> Hi, how do I get FDE augmentation data?

If using Dwarf_CFI_Entry then see
https://sourceware.org/ml/elfutils-devel/2017-q3/msg00017.html
on how to access the CIE augmentation data. You then have to hand decode
that to know how the decode the FDE. There is some code that does that
in libdw/fde.c (which constructs the CFI cache which provides the
Dwarf_Frames).

Cheers,

Mark

Re: [PATCH] ppc64: Add HTM SPRs support to readelf

[Mark Wielaard]

On Thu, 2017-07-20 at 17:49 -0400, Gustavo Romero wrote:
> Since POWER8, PowerPC 64 supports Hardware Transactional Memory, which has
> three special purpose registers associated to it: tfhar, tfiar, and texasr.
> This commit add HTM SPRs set as known note type so it's possible to use
> 'readelf --notes' to inspect the HTM SPRs in a coredump file generated in
> such a machines.

This patch looks perfect, thanks.

One nitpick.

> diff --git a/libelf/ChangeLog b/libelf/ChangeLog
> index 594bec9..e5529e9 100644
> --- a/libelf/ChangeLog
> +++ b/libelf/ChangeLog
> @@ -1,3 +1,7 @@
> +2017-07-19  Gustavo Romero 
> +
> + * elf.h: Add known type in notes segment descriptor for HTM SPRs.
> +
>  2017-04-20  Ulf Hermann  
>  
>   * libelfP.h: Don't include config.h.
> diff --git a/libelf/elf.h b/libelf/elf.h
> index b6112d9..fa35203 100644
> --- a/libelf/elf.h
> +++ b/libelf/elf.h
> @@ -763,6 +763,7 @@ typedef struct
>  #define NT_PPC_SPE   0x101   /* PowerPC SPE/EVR registers */
>  #define NT_PPC_VSX   0x102   /* PowerPC VSX registers */
>  #define NT_386_TLS   0x200   /* i386 TLS slots (struct user_desc) */
> +#define NT_PPC_TM_SPR0x10c   /* PowerPC HW Transactional 
> Memory SPRs */
>  #define NT_386_IOPERM0x201   /* x86 io permission bitmap 
> (1=deny) */
>  #define NT_X86_XSTATE0x202   /* x86 extended state using 
> xsave */
>  #define NT_S390_HIGH_GPRS0x300   /* s390 upper register halves */

We normally keep elf.h in sync with glibc.
Could you submit this elf.h change to libc-al...@sourceware.org?
Then we resync elf.h from glibc to pull in the new constants.

Thanks,

Mark