tmb@AI.MIT.EDU (Thomas M. Breuel) (02/27/90)
Does GDB handle structure return/passing correctly when used
interactively? I have a feeling it doesn't... consider the following
transcript:
Script started on Mon Feb 26 16:10:03 1990
lem$ gdb
Reading symbol data from /tmp_mnt/home/vi/tmb/index/index...done.
Reading in symbols for index.c...done.
Breakpoint 1 at 0x3434: file index.c, line 170.
Bpt 1, main () (index.c line 170)
170 generate_models();
(gdb) p rotatev(makev(1.0,0.0),3.14159)
Program received signal 11, Segmentation fault
0x25f0 in rotatev (p={x = 1, y = 0}, a=3.14159) (./geo.h line 23)
23 q.x=p.x*c-p.y*s;
Cannot continue previously requested operation.
Unable to restore previously selected frame.
(gdb) l rotatev
15 return atan2(p.y,p.x);
16 }
17
18 vec rotatev(p,a)
19 vec p; float a;
20 {
21 float s=sin(a),c=cos(a);
22 vec q;
23 q.x=p.x*c-p.y*s;
24 q.y=p.x*s+p.y*c;
(gdb) l makev
1 typedef struct _vec { float x,y; } vec;
2
3 vec makev(x,y) float x,y; { vec p; p.x=x; p.y=y; return p; }
4 vec addv(p,q) vec p,q; { p.x+=q.x; p.y+=q.y; return p; }
5 vec subv(p,q) vec p,q; { p.x-=q.x; p.y-=q.y; return p; }
6 float normv(p) vec p; { double sqrt(); return sqrt(p.x*p.x+p.y*p.y); }
7 float distancev(p,q) vec p,q; { return normv(subv(p,q)); }
(gdb) p normv(makev(1.0,0.0))
Program received signal 11, Segmentation fault
normv (p={x = 1, y = 0}) (./geo.h line 6)
6 float normv(p) vec p; { double sqrt(); return sqrt(p.x*p.x+p.y*p.y); }
Cannot continue previously requested operation.
Unable to restore previously selected frame.
(gdb) q
The program is running. Quit anyway? (y or n) y
lem$
script done on Mon Feb 26 16:12:30 1990
(This is in GDB 3.5)rfg@ics.uci.edu (Ronald Guilmette) (02/28/90)
In article <9002262118.AA03600@lem> tmb@AI.MIT.EDU (Thomas M. Breuel) writes: >Does GDB handle structure return/passing correctly when used >interactively? I have a feeling it doesn't... consider the following >transcript: Calling sequences are *highly* machine dependent, and thus, there may be a bug in this area that affects only the machine that you are using. Did you remember to *always* include complete (or at least some) information about your configuration when posting your bug report? No. Shame on you. // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
Raeburn@ATHENA.MIT.EDU (Ken Raeburn) (03/01/90)
Date: 27 Feb 90 23:00:10 GMT From: uci-ics!rfg@ORION.OAC.UCI.EDU (Ronald Guilmette) Calling sequences are *highly* machine dependent, and thus, there may be a bug in this area that affects only the machine that you are using. And compiler dependent! On the vax, depending on the compiler used (and whether -fpcc-struct-return is used with gcc), structure returns are done two different ways, and gdb has no way of knowing which a given routine will do, unless perhaps the symbol table information is different, which I doubt....
kingdon@AI.MIT.EDU (Jim Kingdon) (03/01/90)
And compiler dependent! On the vax, depending on the compiler used
(and whether -fpcc-struct-return is used with gcc), structure returns
are done two different ways
Come on, people, this is bug-gdb, not
uninformed-speculations-and-rumors-about-gdb. If you have a bug to
report, report it with a specific example (the sections of the emacs
and gcc manuals on reporting bugs are good reading if you're unsure of
how to write a bug report).
Most follow-ups to messages on this list should go just to the sender,
not to the whole list.