Do arm_abi detection for ELFOSABI_GNU binaries

Message ID CAP045ApGo8tPc=97OqrVG4S9GiAP+T1k0ftrP2L3f-kpCDSdJg@mail.gmail.com
State New, archived
Headers

Commit Message

Kyle Huey March 27, 2015, 8:55 p.m. UTC
  On ARM systems, gdb must determine which style of breakpoint to use
(see the comments at the beginning of gdb/arm-linux-tdep.c).  In
arm_gdbarch_init we only attempt to extract the eabi version from the
ELF binary if it is a ELFOSABI_NONE binary.  If the binary is
ELFOSABI_GNU instead, we end up defaulting to the old style OABI
syscall breakpoint instruction.  On a Linux kernel built without
CONFIG_OABI_COMPAT, this triggers a SIGILL in ld when attempting to
execute any ELFOSABI_GNU program.  (e.g.
https://github.com/raspberrypi/linux/issues/766)

gdb/ChangeLog:
    * gdb/arm-tdep.c (arm_gdbarch_init): Perform arm_abi detection on
ELFOSABI_GNU binaries.
---
 gdb/arm-tdep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

           /* Assume GNU tools.  */
  

Comments

Kyle Huey April 16, 2015, 5:15 p.m. UTC | #1
On Fri, Mar 27, 2015 at 1:55 PM, Kyle Huey <me@kylehuey.com> wrote:
> On ARM systems, gdb must determine which style of breakpoint to use
> (see the comments at the beginning of gdb/arm-linux-tdep.c).  In
> arm_gdbarch_init we only attempt to extract the eabi version from the
> ELF binary if it is a ELFOSABI_NONE binary.  If the binary is
> ELFOSABI_GNU instead, we end up defaulting to the old style OABI
> syscall breakpoint instruction.  On a Linux kernel built without
> CONFIG_OABI_COMPAT, this triggers a SIGILL in ld when attempting to
> execute any ELFOSABI_GNU program.  (e.g.
> https://github.com/raspberrypi/linux/issues/766)
>
> gdb/ChangeLog:
>     * gdb/arm-tdep.c (arm_gdbarch_init): Perform arm_abi detection on
> ELFOSABI_GNU binaries.
> ---
>  gdb/arm-tdep.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> index 630a207..830739e 100644
> --- a/gdb/arm-tdep.c
> +++ b/gdb/arm-tdep.c
> @@ -9948,17 +9948,17 @@ arm_gdbarch_init (struct gdbarch_info info,
> struct gdbarch_list *arches)
>
>        if (ei_osabi == ELFOSABI_ARM)
>          {
>            /* GNU tools used to use this value, but do not for EABI
>           objects.  There's nowhere to tag an EABI version
>           anyway, so assume APCS.  */
>            arm_abi = ARM_ABI_APCS;
>          }
> -      else if (ei_osabi == ELFOSABI_NONE)
> +      else if (ei_osabi == ELFOSABI_NONE || ei_osabi == ELFOSABI_GNU)
>          {
>            int eabi_ver = EF_ARM_EABI_VERSION (e_flags);
>            int attr_arch, attr_profile;
>
>            switch (eabi_ver)
>          {
>          case EF_ARM_EABI_UNKNOWN:
>            /* Assume GNU tools.  */

Bump.  Has anyone had a chance to review this?

- Kyle
  
Yao Qi April 17, 2015, 8:41 a.m. UTC | #2
Kyle Huey <me@kylehuey.com> writes:

Hi Kyle,

> On ARM systems, gdb must determine which style of breakpoint to use
> (see the comments at the beginning of gdb/arm-linux-tdep.c).  In
> arm_gdbarch_init we only attempt to extract the eabi version from the
> ELF binary if it is a ELFOSABI_NONE binary.  If the binary is
> ELFOSABI_GNU instead, we end up defaulting to the old style OABI
> syscall breakpoint instruction.  On a Linux kernel built without
> CONFIG_OABI_COMPAT, this triggers a SIGILL in ld when attempting to
> execute any ELFOSABI_GNU program.  (e.g.
> https://github.com/raspberrypi/linux/issues/766)

Thanks for submitting the patch... Looks GDB doesn't detect the correct
abi in your case, but you can set arm abi explicitly via "set arm abi AAPCS".
Hope this can unblock you.  In the mean time, I'll think about your patch.
  
Kyle Huey May 8, 2015, 5:11 p.m. UTC | #3
On Fri, Apr 17, 2015 at 1:41 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
> Kyle Huey <me@kylehuey.com> writes:
>
> Hi Kyle,
>
>> On ARM systems, gdb must determine which style of breakpoint to use
>> (see the comments at the beginning of gdb/arm-linux-tdep.c).  In
>> arm_gdbarch_init we only attempt to extract the eabi version from the
>> ELF binary if it is a ELFOSABI_NONE binary.  If the binary is
>> ELFOSABI_GNU instead, we end up defaulting to the old style OABI
>> syscall breakpoint instruction.  On a Linux kernel built without
>> CONFIG_OABI_COMPAT, this triggers a SIGILL in ld when attempting to
>> execute any ELFOSABI_GNU program.  (e.g.
>> https://github.com/raspberrypi/linux/issues/766)
>
> Thanks for submitting the patch... Looks GDB doesn't detect the correct
> abi in your case, but you can set arm abi explicitly via "set arm abi AAPCS".
> Hope this can unblock you.  In the mean time, I'll think about your patch.
>
> --
> Yao (齐尧)

Hello Yao,

Thank you for the tip.  Have you had a chance to look at the patch?

- Kyle
  
Yao Qi May 19, 2015, 9:41 a.m. UTC | #4
Kyle Huey <me@kylehuey.com> writes:

> Thank you for the tip.  Have you had a chance to look at the patch?

Hi Kyle,
Sorry for the delayed reply.  I spent some hours investigating how this
patch break some cases, but can't find any one.  I also take a look at
code in binutils, and find the code pattern
"e_ident[EI_OSABI] == ELFOSABI_GNU || e_ident[EI_OSABI] == ELFOSABI_NONE"
is used here and there.

This patch is OK to commit.  If you don't have a sourceware account to
push your commit in, I can do it for you.  Your patch is just one line,
so it can be pushed in as a "tiny patch".
  
Kyle Huey May 19, 2015, 2:04 p.m. UTC | #5
On Tue, May 19, 2015 at 2:41 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
> Kyle Huey <me@kylehuey.com> writes:
>
>> Thank you for the tip.  Have you had a chance to look at the patch?
>
> Hi Kyle,
> Sorry for the delayed reply.  I spent some hours investigating how this
> patch break some cases, but can't find any one.  I also take a look at
> code in binutils, and find the code pattern
> "e_ident[EI_OSABI] == ELFOSABI_GNU || e_ident[EI_OSABI] == ELFOSABI_NONE"
> is used here and there.
>
> This patch is OK to commit.  If you don't have a sourceware account to
> push your commit in, I can do it for you.  Your patch is just one line,
> so it can be pushed in as a "tiny patch".
>
> --
> Yao (齐尧)

Thanks for reviewing!  I do not have a sourceware account, so that
would be greatly appreciated.

Thanks,

- Kyle
  
Yao Qi May 28, 2015, 8:19 a.m. UTC | #6
Kyle Huey <me@kylehuey.com> writes:

> Thanks for reviewing!  I do not have a sourceware account, so that
> would be greatly appreciated.

I pushed this patch in.  Thanks for reminding me...  I thought I did
push it in already :)
  

Patch

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 630a207..830739e 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -9948,17 +9948,17 @@  arm_gdbarch_init (struct gdbarch_info info,
struct gdbarch_list *arches)

       if (ei_osabi == ELFOSABI_ARM)
         {
           /* GNU tools used to use this value, but do not for EABI
          objects.  There's nowhere to tag an EABI version
          anyway, so assume APCS.  */
           arm_abi = ARM_ABI_APCS;
         }
-      else if (ei_osabi == ELFOSABI_NONE)
+      else if (ei_osabi == ELFOSABI_NONE || ei_osabi == ELFOSABI_GNU)
         {
           int eabi_ver = EF_ARM_EABI_VERSION (e_flags);
           int attr_arch, attr_profile;

           switch (eabi_ver)
         {
         case EF_ARM_EABI_UNKNOWN: