From: Joel Brobecker <brobecker@gnat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA/mips] Fix crash trying to print long double float
Date: Fri, 06 Aug 2004 18:16:00 -0000 [thread overview]
Message-ID: <20040806181603.GQ1203@gnat.com> (raw)
Restarting the discussion that started with:
http://sources.redhat.com/ml/gdb-patches/2004-07/msg00290.html
And then continued in:
http://sources.redhat.com/ml/gdb-patches/2004-07/msg00310.html
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
126 l = add_doublest (l, r);
(gdb) p l
zsh: 6356790 segmentation fault (core dumped) ../../gdb store
The problem is that GDB is currently "configured" via the gdbarch
mechanism to think that "long double" types are 64bits long, when
they are in fact 128 bits long.
When we try to print the value of "l", a 128bit long variable (the
size is deduced from the debugging info), GDB does a floatformat lookup
based on type size. At some point, GDB calls the following function with
a length of 16 bytes:
static const struct floatformat *
floatformat_from_length (int len)
{
if (len * TARGET_CHAR_BIT == TARGET_FLOAT_BIT)
return TARGET_FLOAT_FORMAT;
else if (len * TARGET_CHAR_BIT == TARGET_DOUBLE_BIT)
return TARGET_DOUBLE_FORMAT;
else if (len * TARGET_CHAR_BIT == TARGET_LONG_DOUBLE_BIT)
return TARGET_LONG_DOUBLE_FORMAT;
/* On i386 the 'long double' type takes 96 bits,
while the real number of used bits is only 80,
both in processor and in memory.
The code below accepts the real bit size. */
else if ((TARGET_LONG_DOUBLE_FORMAT != NULL)
&& (len * TARGET_CHAR_BIT ==
TARGET_LONG_DOUBLE_FORMAT->totalsize))
return TARGET_LONG_DOUBLE_FORMAT;
return NULL;
}
Because the gdbarch vector tells GDB that TARGET_LONG_DOUBLE_BIT = 64bit,
we end up returning a NULL floatformat. And unfortunately for us, we
immediatly use that NULL floatformat to feed it to floatformat_is_valid(),
which dereferences it without checking that it's not NULL before hand.
This causes the SEGV. See values.c:unpack_double():
if (!floatformat_is_valid (floatformat_from_type (type), valaddr))
{
*invp = 1;
return 0.0;
}
The first thing that needs to be fixed in the size of long doubles.
The attached patch fixes this, and prevents the crash from happening.
There is a discussion regarding the long double floatformat used, which
happens to work, but only by chance. This will be the subject of another
patch.
2004-08-06 Joel Brobecker <brobecker@gnat.com>
* mips-tdep.c (mips_gdbarch_init): Set size of long double
to 128 bits for N32 and N64 ABIs.
Tested on mips-irix. OK to apply?
Thanks,
--
Joel
next reply other threads:[~2004-08-06 18:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-06 18:16 Joel Brobecker [this message]
2004-08-06 20:24 ` Andrew Cagney
2004-08-06 20:38 ` Joel Brobecker
2004-08-06 21:03 ` Andrew Cagney
2004-08-07 17:18 ` Andrew Cagney
2004-08-06 20:32 ` Joel Brobecker
2004-08-07 18:01 ` Andrew Cagney
2004-08-07 18:09 ` Joel Brobecker
2004-08-07 18:22 ` Andrew Cagney
2004-08-08 6:59 ` Joel Brobecker
2004-08-08 16:57 ` Andrew Cagney
2004-08-09 5:46 ` Joel Brobecker
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=20040806181603.GQ1203@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