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

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

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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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)
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html