Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA] mips-irix SEGV: long doubles are 128 bits long on IRIX
Date: Wed, 21 Jul 2004 21:25:00 -0000	[thread overview]
Message-ID: <20040721212522.GP1278@gnat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

Hello,

I noticed the following SEGV in our testsuite. Here is below how to
reproduce it using the store.c sources in testsuite/gdb.base:

        % gcc -c -g store.c
        % gcc -o store store.o

The following transcript shows how to cause the SEGV:

        (gdb) b wack_doublest
        Breakpoint 1 at 0x1000256c: file store.c, line 125.
        (gdb) run
        Starting program: /[...]/gdb.base/store

        Breakpoint 1, wack_doublest (u=Unhandled dwarf expression opcode 0x93
        ) at store.c:125
        125       register doublest l = u, r = v;
        (gdb) n
        warning: GDB can't find the start of the function at 0x100108d4.

            GDB is unable to find the start of the function at 0x100108d4
        and thus can't determine the size of that function's stack frame.
        This means that GDB may be unable to access that stack frame, or
        the frames below it.
            This problem is most likely caused by an invalid program counter or
        stack pointer.
            However, if you think GDB should simply search farther back
        from 0x100108d4 for code which looks like the beginning of a
        function, you can increase the range of the search using the `set
        heuristic-fence-post' command.
        126       l = add_doublest (l, r);
        (gdb) p l
        zsh: 6356790 segmentation fault (core dumped)  ../../gdb store

We'll ignore the 2 warnings for now ("opcode 0x93" = OP_piece, and
"can't find start of function at 0x..."), and focus on the SEGV.

The problem is that GDB thinks that long double variables are 64 bits
long, but they are in fact 128 bits long. The discrepancy causes GDB
to fail to find the associated format for type doublest (which is
a typedef of long double), and then call floatformat_is_valid() with
a NULL format... See values.c:unpack_double():

      if (!floatformat_is_valid (floatformat_from_type (type), valaddr))
        {
          *invp = 1;
          return 0.0;
        }

The attached patch should fixes the problem (on 032, the SGI compiler
claims that "long double" is not supported on implicitly changes them
into plain "double" types (64bit), while GCC says they are 64bit).

2004-07-21  Joel Brobecker  <brobecker@gnat.com>

        * mips-irix-tdep.c: #include "mips-tdep.h".
        (mips_irix_init_abi): Set size of long double to 128 bits
        for N32 and N64 ABIs.
        * Makefile.in (mips-irix-tdep.o): Add dependency on mips-tdep.h.

Tested on mips-irix, fixes the problem above and many other FAILs.
OK to commit?

As for the 6.2 branch, my guess is that it would need this fix as well.
But I haven't looked at it, because I am already too overloaded with
work. There is also the bfd patch I just submitted, too.

-- 
Joel

[-- Attachment #2: irix.diff --]
[-- Type: text/plain, Size: 1832 bytes --]

Index: mips-irix-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-irix-tdep.c,v
retrieving revision 1.2
diff -u -p -r1.2 mips-irix-tdep.c
--- mips-irix-tdep.c	21 Dec 2002 19:58:07 -0000	1.2
+++ mips-irix-tdep.c	21 Jul 2004 21:18:45 -0000
@@ -24,6 +24,7 @@
 #include "osabi.h"
 
 #include "elf-bfd.h"
+#include "mips-tdep.h"
 
 static void
 mips_irix_elf_osabi_sniff_abi_tag_sections (bfd *abfd, asection *sect,
@@ -80,6 +81,20 @@ static void
 mips_irix_init_abi (struct gdbarch_info info,
                     struct gdbarch *gdbarch)
 {
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  enum mips_abi abi = mips_abi (gdbarch);
+
+  switch (abi)
+    {
+      case MIPS_ABI_O32:
+         break;
+      case MIPS_ABI_N32:
+      case MIPS_ABI_N64:
+         set_gdbarch_long_double_bit (gdbarch, 128);
+         break;
+      default:
+         internal_error (__FILE__, __LINE__, "unexpected ABI");
+    }
 }
 
 void
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.595
diff -u -p -r1.595 Makefile.in
--- Makefile.in	17 Jul 2004 11:03:46 -0000	1.595
+++ Makefile.in	21 Jul 2004 21:18:56 -0000
@@ -2113,7 +2113,8 @@ mem-break.o: mem-break.c $(defs_h) $(sym
 	$(target_h)
 minsyms.o: minsyms.c $(defs_h) $(gdb_string_h) $(symtab_h) $(bfd_h) \
 	$(symfile_h) $(objfiles_h) $(demangle_h) $(value_h) $(cp_abi_h)
-mips-irix-tdep.o: mips-irix-tdep.c $(defs_h) $(osabi_h) $(elf_bfd_h)
+mips-irix-tdep.o: mips-irix-tdep.c $(defs_h) $(osabi_h) $(elf_bfd_h) \
+	$(mips_tdep_h)
 mips-linux-nat.o: mips-linux-nat.c $(defs_h) $(mips_tdep_h)
 mips-linux-tdep.o: mips-linux-tdep.c $(defs_h) $(gdbcore_h) $(target_h) \
 	$(solib_svr4_h) $(osabi_h) $(mips_tdep_h) $(gdb_string_h) \

             reply	other threads:[~2004-07-21 21:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-21 21:25 Joel Brobecker [this message]
2004-07-21 21:30 ` Daniel Jacobowitz
2004-07-21 23:33   ` Joel Brobecker
2004-07-22  0:40     ` Daniel Jacobowitz
2004-07-22  0:46       ` Joel Brobecker
2004-07-22  0:49         ` Daniel Jacobowitz
     [not found]           ` <mailpost.1090457371.25819@news-sj1-1>
2004-07-22  1:19             ` cgd
2004-07-22  1:27               ` Daniel Jacobowitz
2004-07-22  2:09           ` Joel Brobecker
2004-07-22  2:21             ` Daniel Jacobowitz
2004-07-22  2:34               ` Joel Brobecker
2004-07-22  2:36                 ` Daniel Jacobowitz
2004-07-23 17:00 David Anderson
2004-07-26 22:18 ` Andrew Cagney
     [not found]   ` <mailpost.1090880398.10041@news-sj1-1>
2004-07-26 22:41     ` cgd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040721212522.GP1278@gnat.com \
    --to=brobecker@gnat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox