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

[John David Anglin]

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.

>
> Thanks!
> Helge
>
>
> diff --git a/binutils/readelf.c b/binutils/readelf.c
> index 8a61db6459..3d239d3ab2 100644
> --- a/binutils/readelf.c
> +++ b/binutils/readelf.c
> @@ -6090,6 +6090,11 @@ process_section_headers (Filedata * filedata)
>   	  break;
>   	}
>         break;
> +
> +    case EM_PARISC:
> +      /* ELF64 uses 32-bit unwind entries too.  */
> +      eh_addr_size = 4;
> +      break;
>       }
>   
>   #define CHECK_ENTSIZE_VALUES(section, i, size32, size64)		\
>
Thanks,
Dave

-- 
John David Anglin  dave.anglin@bell.net