[PATCH] binutils/readelf: Fix unwind entries of 64-bit hppa object files

[Alan Modra]

On Thu, Aug 16, 2018 at 09:54:47AM -0400, John David Anglin wrote:
> On 2018-08-15 3:36 AM, Helge Deller wrote:
> > * Alan Modra <amodra@gmail.com>:
> > > On Tue, Aug 14, 2018 at 06:03:29PM +0200, Helge Deller wrote:
> > > >          * readelf.c (slurp_hppa_unwind_table): Replace "eh_addr_size" with "4".
> > > hppa_process_unwind also uses eh_addr_size.  Do you see the correct
> > > number of entries reported?
> > You are right. I didn't noticed, but my old patch reported a wrong
> > number of unwind entries.
> > 
> > > Rather than this patch, I suspect you should set eh_addr_size in
> > > process_section_headers.
> > Yes. The patch below fixes both issues.
> I tried the change below on various kernel .o files and a vmlinux (64-bit)
> file.  The kernel was built
> with -ffunction-sections.  While the change is no doubt an improvement,
> "readelf -u" still seems
> broken/useless.  The ranges displayed for vmlinux don't seem to correspond
> to the addresses
> displayed with "objdump -d".  I see lots of "symbol + n" entries in the
> readelf output.  The symbol
> matching for .o files also doesn't work at all reliably.  Maybe it's better
> when -ffunction-stections
> isn't used.
> 
> Do 64-bit kernel backtraces work?
> 
> We need to determine if gas is correctly generating unwind entries. If it
> is, I think we have further
> issues with readelf.

Huh, yes, confusion reigns.  There are two possible unwind sections to
consider, .PARISC.unwind and .eh_frame.  As things are at the moment,
it looks to me that eh_addr_size of 4 is needed for .PARISC.unwind and
8 for .eh_frame.  I'm basing that on the fact that tc-hppa.c 
pa_build_unwind_subspace emits 4-byte entries to .PARISC.unwind, while
DWARF2_FDE_RELOC_SIZE is 8 for hppa64, leading to 8-byte addresses if
you use .cfi directives to generate .eh_frame.

So the proper fix for readelf looks to be the following, which
incidentally makes slurp_hppa_unwind_table self-consistent (it always
reads 4-byte start and end offsets.)

>From 43f6cd0588a735c202934789d67b6ed4302f255d Mon Sep 17 00:00:00 2001
From: Alan Modra <amodra@gmail.com>
Date: Wed, 10 Oct 2018 13:14:56 +1030
Subject: [PATCH 2/4] HPPA64 .PARISC.unwind entries

.PARISC.unwind has 32-bit addresses in both 32-bit ELF and 64-bit ELF.
Well, strictly speaking, the 32-bit "start" and "end" fields are
segment relative offsets.  (The 64-bit ABI says so, while the 32-bit
ABI says they are addresses but it appears they are segment relative
offsets in practice.  Likely the 32-bit ABI lacks an update.)

	* readelf.c (hppa_process_unwind): Don't use eh_addr_size to
	calculate number of entries.
	(slurp_hppa_unwind_table): Don't use eh_addr_size here either.

diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index 09436ccedc..fd568340df 100644
--- a/binutils/ChangeLog
+++ b/binutils/ChangeLog
@@ -1,3 +1,10 @@
+2018-10-10  Helge Deller <deller@gmx.de>
+	    Alan Modra  <amodra@gmail.com>
+
+	* readelf.c (hppa_process_unwind): Don't use eh_addr_size to
+	calculate number of entries.
+	(slurp_hppa_unwind_table): Don't use eh_addr_size here either.
+
 2018-10-10  Alan Modra  <amodra@gmail.com>
 
 	* objdump.c (dump_dwarf): Set s12z eh_addr_size to 4.
diff --git a/binutils/readelf.c b/binutils/readelf.c
index 2748664a30..41f55ee4ed 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -8065,7 +8065,7 @@ slurp_hppa_unwind_table (Filedata *                  filedata,
 
 	  i = rp->r_offset / unw_ent_size;
 
-	  switch ((rp->r_offset % unw_ent_size) / eh_addr_size)
+	  switch ((rp->r_offset % unw_ent_size) / 4)
 	    {
 	    case 0:
 	      aux->table[i].start.section = sym->st_shndx;
@@ -8133,7 +8133,7 @@ hppa_process_unwind (Filedata * filedata)
     {
       if (streq (SECTION_NAME (sec), ".PARISC.unwind"))
 	{
-	  unsigned long num_unwind = sec->sh_size / (2 * eh_addr_size + 8);
+	  unsigned long num_unwind = sec->sh_size / 16;
 
 	  printf (ngettext ("\nUnwind section '%s' at offset 0x%lx "
 			    "contains %lu entry:\n",

-- 
Alan Modra
Australia Development Lab, IBM