Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* gdb segfaults when printing long double complex variables
@ 2004-06-10 19:30 Peter Jay Salzman
  2004-06-10 19:39 ` Daniel Jacobowitz
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Jay Salzman @ 2004-06-10 19:30 UTC (permalink / raw)
  To: Gdb Mailing List

Bug: GDB segfaults when printing long double complex variables.

Sample Code:

1       #include <tgmath.h>
2       #include <stdio.h>
3
4       int main(void)
5       {
6               complex a;
7               double complex b;
8               long double complex c;
9
10              a = 5 + 2I;
11              printf("%f + %fi\n", __real__ a, __imag__ a);
12
13              b = 5.0 + 2.0I;
14              printf("%f + %fi\n", __real__ b, __imag__ b);
15
16              c = 5.0L + 2.0LI;
17              printf("%Lf + %Lfi\n", __real__ c, __imag__ c);
18
19              return 0;
20      }



The program runs fine:

   p@satan$ gcc-3.3 -g -W -Wall blah.c 
   p@satan$ ./a.out 
   5.000000 + 2.000000i
   5.000000 + 2.000000i
   5.000000 + 2.000000i

The program runs fine under gdb:

   (gdb) run
   Starting program: /home/p/a.out 
   5.000000 + 2.000000i
   5.000000 + 2.000000i
   5.000000 + 2.000000i

   Program exited normally.

But GDB itself cannot print long double complex variables without
segfaulting:

   (gdb) break 18
   Breakpoint 1 at 0x8048436: file blah.c, line 18.
   (gdb) run
   Starting program: /home/p/a.out 
   5.000000 + 2.000000i
   5.000000 + 2.000000i
   5.000000 + 2.000000i

   Breakpoint 1, main () at blah.c:19
   19              return 0;
   (gdb) p a
   $1 = 5 + 2 * I
   (gdb) p b
   $2 = 5 + 2 * I
   (gdb) p c
   Segmentation fault (core dumped)

This is very reproducible, unfortunately.  This bug showed up at the
worst possible moment...

Pete

-- 
In theory, theory and practise are the same.  In practise, they aren't.
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gdb segfaults when printing long double complex variables
  2004-06-10 19:30 gdb segfaults when printing long double complex variables Peter Jay Salzman
@ 2004-06-10 19:39 ` Daniel Jacobowitz
  2004-06-10 19:59   ` Peter Jay Salzman
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Jacobowitz @ 2004-06-10 19:39 UTC (permalink / raw)
  To: Peter Jay Salzman; +Cc: Gdb Mailing List

On Thu, Jun 10, 2004 at 12:28:29PM -0700, Peter Jay Salzman wrote:
> Bug: GDB segfaults when printing long double complex variables.
> 
> Sample Code:
> 
> 1       #include <tgmath.h>
> 2       #include <stdio.h>
> 3
> 4       int main(void)
> 5       {
> 6               complex a;
> 7               double complex b;
> 8               long double complex c;
> 9
> 10              a = 5 + 2I;
> 11              printf("%f + %fi\n", __real__ a, __imag__ a);
> 12
> 13              b = 5.0 + 2.0I;
> 14              printf("%f + %fi\n", __real__ b, __imag__ b);
> 15
> 16              c = 5.0L + 2.0LI;
> 17              printf("%Lf + %Lfi\n", __real__ c, __imag__ c);
> 18
> 19              return 0;
> 20      }

GDB doesn't really support complex long double.  The entire type
infrastructure for complex types is hokey and special-cases based on
the size of the type; it expects 128-bit long double rather than x86's
96-bit.

Look in dwarf2read.c for the code setting TYPE_TARGET_TYPE if you want
to work around it.

-- 
Daniel Jacobowitz


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gdb segfaults when printing long double complex variables
  2004-06-10 19:39 ` Daniel Jacobowitz
@ 2004-06-10 19:59   ` Peter Jay Salzman
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Jay Salzman @ 2004-06-10 19:59 UTC (permalink / raw)
  To: Gdb Mailing List

On Thu 10 Jun 04,  3:39 PM, Daniel Jacobowitz <drow@false.org> said:
> On Thu, Jun 10, 2004 at 12:28:29PM -0700, Peter Jay Salzman wrote:
> > Bug: GDB segfaults when printing long double complex variables.
> > 
> > Sample Code:
> > 
> > 1       #include <tgmath.h>
> > 2       #include <stdio.h>
> > 3
> > 4       int main(void)
> > 5       {
> > 6               complex a;
> > 7               double complex b;
> > 8               long double complex c;
> > 9
> > 10              a = 5 + 2I;
> > 11              printf("%f + %fi\n", __real__ a, __imag__ a);
> > 12
> > 13              b = 5.0 + 2.0I;
> > 14              printf("%f + %fi\n", __real__ b, __imag__ b);
> > 15
> > 16              c = 5.0L + 2.0LI;
> > 17              printf("%Lf + %Lfi\n", __real__ c, __imag__ c);
> > 18
> > 19              return 0;
> > 20      }
> 
> GDB doesn't really support complex long double.  The entire type
> infrastructure for complex types is hokey and special-cases based on
> the size of the type; it expects 128-bit long double rather than x86's
> 96-bit.
> 
> Look in dwarf2read.c for the code setting TYPE_TARGET_TYPE if you want
> to work around it.

Hi Daniel,

A friend noticed that it worked on an Opteron, which presumably has 128
bit long double complexes.  But two questions:

1. Should GDB be segfaulting?  Isn't there a nicer way to alert
   the user that there's a problem?

2. Is support planned?  If so, for what time estimate?  I use C to
   solve non-linear Schrodinger equations.  Hokey under the hood or not,
   I'd really rather use native complexes rather than home brewed
   structs.

Pete

ps- Queen of the Demonweb Pits was my favorite module...

-- 
In theory, theory and practise are the same.  In practise, they aren't.
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-06-10 19:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-10 19:30 gdb segfaults when printing long double complex variables Peter Jay Salzman
2004-06-10 19:39 ` Daniel Jacobowitz
2004-06-10 19:59   ` Peter Jay Salzman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox