[Patch V2 1/2] sparc64 changes for gdb-7.6

[Patch V2 1/2] sparc64 changes for gdb-7.6

[Dave Kleikamp]

Originally by Karl Volz <karl.volz@oracle.com>
---
 gdb-7.6.patch |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/gdb-7.6.patch b/gdb-7.6.patch
index 5bd9b0c..8b2d5c8 100644
--- a/gdb-7.6.patch
+++ b/gdb-7.6.patch
@@ -2044,3 +2044,40 @@ diff -up gdb-7.6/bfd/elf64-ppc.c.orig gdb-7.6/bfd/elf64-ppc.c
  		  {
  		    struct type *target = TYPE_TYPEDEF_FIELD_TYPE (type, i);
  
+diff -up gdb-7.6/gdb/dwarf2read.c.old gdb-7.6/gdb/dwarf2read.c
+--- gdb-7.6/gdb/dwarf2read.c.old	2014-02-11 10:29:01.668110122 -0800
++++ gdb-7.6/gdb/dwarf2read.c	2014-02-11 14:13:30.257151330 -0800
+@@ -84,6 +84,10 @@ static int dwarf2_read_debug = 0;
+ /* When non-zero, dump DIEs after they are read in.  */
+ static unsigned int dwarf2_die_debug = 0;
+ 
++#if defined(__sparc__) && __WORDSIZE = 64
++static int pagesize;
++#endif
++
+ /* When non-zero, cross-check physname against demangler.  */
+ static int check_physname = 0;
+ 
+@@ -1932,9 +1936,21 @@ dwarf2_read_section (struct objfile *obj
+ 
+   abfd = sectp->owner;
+ 
++#if defined(__sparc__) && __WORDSIZE = 64
++  if (pagesize = 0)
++    pagesize = getpagesize ();
++#endif
++
+   /* If the section has relocations, we must read it ourselves.
+-     Otherwise we attach it to the BFD.  */
++     Otherwise we attach it to the BFD.  
++     Also, in sparc64 only try mmap for sections which
++     are properly aligned in order to avoid SIGBUS errors.  */
++
++#if defined(__sparc__) && __WORDSIZE = 64
++  if (info->size > 4 * pagesize && (sectp->flags & SEC_RELOC) = 0 && !(sectp->filepos & 0x3))
++#else
+   if ((sectp->flags & SEC_RELOC) = 0)
++#endif
+     {
+       const gdb_byte *bytes = gdb_bfd_map_section (sectp, &info->size);
+ 
-- 
1.7.1

Re: [Patch V2 1/2] sparc64 changes for gdb-7.6

[David Miller]

From: Dave Kleikamp <dave.kleikamp@oracle.com>
Date: Wed, 23 Mar 2016 17:41:07 -0500

> +   /* If the section has relocations, we must read it ourselves.
> +-     Otherwise we attach it to the BFD.  */
> ++     Otherwise we attach it to the BFD.  
> ++     Also, in sparc64 only try mmap for sections which
> ++     are properly aligned in order to avoid SIGBUS errors.  */
> ++
> ++#if defined(__sparc__) && __WORDSIZE = 64
> ++  if (info->size > 4 * pagesize && (sectp->flags & SEC_RELOC) = 0 && !(sectp->filepos & 0x3))
> ++#else
> +   if ((sectp->flags & SEC_RELOC) = 0)
> ++#endif
> +     {
> +       const gdb_byte *bytes = gdb_bfd_map_section (sectp, &info->size);

This doesn't make any sense at all.

The bug is probably that unaligned relocations are being improperly
accessed using 32-bit loads and storess them.

Several relocs, particularly those used in debugging sections, need to
be carefully accessed using byte at a time accesses in order to avoid
said SIGBUS problem.

BFD and the rest of binutils have code to handle this case properly.

Please don't paper over the core issue with hacks like this.

Thanks.

Re: [Patch V2 1/2] sparc64 changes for gdb-7.6

[Dave Kleikamp]

On 03/24/2016 02:20 PM, David Miller wrote:
> From: Dave Kleikamp <dave.kleikamp@oracle.com>
> Date: Wed, 23 Mar 2016 17:41:07 -0500
> 
>> +   /* If the section has relocations, we must read it ourselves.
>> +-     Otherwise we attach it to the BFD.  */
>> ++     Otherwise we attach it to the BFD.  
>> ++     Also, in sparc64 only try mmap for sections which
>> ++     are properly aligned in order to avoid SIGBUS errors.  */
>> ++
>> ++#if defined(__sparc__) && __WORDSIZE = 64
>> ++  if (info->size > 4 * pagesize && (sectp->flags & SEC_RELOC) = 0 && !(sectp->filepos & 0x3))
>> ++#else
>> +   if ((sectp->flags & SEC_RELOC) = 0)
>> ++#endif
>> +     {
>> +       const gdb_byte *bytes = gdb_bfd_map_section (sectp, &info->size);
> 
> This doesn't make any sense at all.
> 
> The bug is probably that unaligned relocations are being improperly
> accessed using 32-bit loads and storess them.
> 
> Several relocs, particularly those used in debugging sections, need to
> be carefully accessed using byte at a time accesses in order to avoid
> said SIGBUS problem.
> 
> BFD and the rest of binutils have code to handle this case properly.
> 
> Please don't paper over the core issue with hacks like this.

I have to admit that I don't know the whole story here. I took over the
crash port, but haven't had to touch the gdb patch that got handed to
me. What I do know is crash works off an older 7.6 branch of gdb. I'll
get back to you after I talk to some other folks.

Thanks,
Dave

Re: [Patch V2 1/2] sparc64 changes for gdb-7.6

[David Miller]

From: Dave Kleikamp <dave.kleikamp@oracle.com>
Date: Thu, 24 Mar 2016 16:01:10 -0500

> I have to admit that I don't know the whole story here. I took over the
> crash port, but haven't had to touch the gdb patch that got handed to
> me. What I do know is crash works off an older 7.6 branch of gdb. I'll
> get back to you after I talk to some other folks.

Ok, if you can reproduce the unaligned acces just get a backtrace and
I think that might help us understand the true issue more quickly.

Re: [Patch V2 1/2] sparc64 changes for gdb-7.6

[Dave Kleikamp]

On 03/24/2016 07:21 PM, David Miller wrote:
> From: Dave Kleikamp <dave.kleikamp@oracle.com>
> Date: Thu, 24 Mar 2016 16:01:10 -0500
> 
>> I have to admit that I don't know the whole story here. I took over the
>> crash port, but haven't had to touch the gdb patch that got handed to
>> me. What I do know is crash works off an older 7.6 branch of gdb. I'll
>> get back to you after I talk to some other folks.
> 
> Ok, if you can reproduce the unaligned acces just get a backtrace and
> I think that might help us understand the true issue more quickly.

I'm not sure that is still even needed. It was a workaround that wasn't
meant to be sent upstream, but I didn't know any better. I'll get it
figured out tomorrow.

Re: [Patch V2 1/2] sparc64 changes for gdb-7.6

[Dave Kleikamp]

On 03/24/2016 07:21 PM, David Miller wrote:
> From: Dave Kleikamp <dave.kleikamp@oracle.com>
> Date: Thu, 24 Mar 2016 16:01:10 -0500
> 
>> I have to admit that I don't know the whole story here. I took over the
>> crash port, but haven't had to touch the gdb patch that got handed to
>> me. What I do know is crash works off an older 7.6 branch of gdb. I'll
>> get back to you after I talk to some other folks.
> 
> Ok, if you can reproduce the unaligned acces just get a backtrace and
> I think that might help us understand the true issue more quickly.

Dave A.,
Please ignore this first patch. It was a workaround for a broken
internal binutils that I've been hanging onto because I didn't have a
need to wade into the internals of gdb to know why it was needed in the
first place.

Thanks for pointing this out, Dave M.

Dave K. (Too many Daves)