This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

exp/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call


>Number:         1155
>Category:       exp
>Synopsis:       s/390 Linux: GDB can't reselect the right frame after an inferior function call
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 27 17:08:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     jimb at redhat dot com
>Release:        unknown-1.0
>Organization:
>Environment:
s390-ibm-linux, GDB 2003-03-27-cvs, gcc (GCC) 3.2.1 20021207 (Red Hat Linux 8.0 3.2.1-2)
>Description:
If you ask GDB to make an inferior function call when the youngest frame is a frameless function, and the selected frame is the second-to-youngest frame, then GDB will not properly re-select the second-to-youngest frame when the inferior call returns.

On the S/390, if a function doesn't use alloca, then the compiler just uses the stack pointer as the frame pointer.  This means that GDB's frame_info structures use the address of the low end of the frame as the frame base, not the high end.  (The S/390 stack grows downwards.)  So, if the youngest function call hasn't allocated any stack space, then its frame base address is equal to that of its caller.  This means that frame_find_by_id is unable to distinguish between the two.

There are comments in various versions of the code that suggest that Andrew (who has been doing lots of frame hacking recently) knows about this; as of 2003-11-29, frame_find_by_id said:

      /* FIXME: cagney/2002-04-21: This isn't sufficient.  It should
	 use id.pc / this.pc to check that the two frames belong to
	 the same function.  Otherwise we'll do things like match
	 dummy frames or mis-match frameless functions.  However,
	 until someone notices, stick with the existing behavour.  */

Okay --- somebody has noticed!  :)

As of 2003-3-27, that comment was gone, but frame_id_eq says:

  /* Add a test to check that the frame ID's are for the same function
     here.  */
  return 1;
>How-To-Repeat:
Run the test script gdb.c++/overload.exp.  If the code generated for marker1 in overload.cc does not allocate any stack space, then after the first call to foo_instance1.overloadargs, all subsequent calls will fail, since foo_instance1 is local to main, but marker1's frame becomes selected after the first call returns.

GNU gdb 2003-03-27-cvs
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "s390-ibm-linux"...
(gdb) break marker1
Breakpoint 1 at 0x40052e: file /home/cygnus/jimb/src/gdb/testsuite/gdb.c++/overload.cc, line 54.
(gdb) run
Starting program: /home/cygnus/jimb/s390/gdb/build/gdb/testsuite/gdb.c++/overload 

Breakpoint 1, marker1() () at /home/cygnus/jimb/src/gdb/testsuite/gdb.c++/overload.cc:54
54      {}
(gdb) up
#1  0x00400612 in main () at /home/cygnus/jimb/src/gdb/testsuite/gdb.c++/overload.cc:83
83          marker1();
(gdb) print foo_instance1.overloadargs (1)
$1 = 1
(gdb) frame
#0  marker1() () at /home/cygnus/jimb/src/gdb/testsuite/gdb.c++/overload.cc:54
54      {}
(gdb) print foo_instance1.overloadargs (1)
No symbol "foo_instance1" in current context.
(gdb) 
>Fix:
It's easy enough for the test suite to recognize and report this failure, but then finish the call to marker1 and continue the overloading tests.  I've attached a patch that does that.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="gdb-5.3post-tests-overload-mar2003.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gdb-5.3post-tests-overload-mar2003.patch"

MjAwMy0wMy0yNyAgSmltIEJsYW5keSAgPGppbWJAcmVkaGF0LmNvbT4KCgkqIGdkYi5jKysvb3Zl
cmxvYWQuZXhwOiBJZiB0aGUgZmlyc3QgY2FsbCB0bwoJZm9vX2luc3RhbmNlMS5vdmVybG9hZGFy
Z3MgY2F1c2VzIHRoZSBzZWxlY3RlZCBmcmFtZSB0byBzaGlmdCBmcm9tCgltYWluIHRvIG1hcmtl
cjEsIHRoZW4gcmVwb3J0IGEgZmFpbHVyZSwgYnV0ICdmaW5pc2gnIHRoZSBjYWxsIHRvCgltYXJr
ZXIxLCBzbyB0aGUgcmVzdCBvZiB0aGUgdGVzdHMgY2FuIHJ1bi4KCioqKiBnZGIrZGVqYWdudS0y
MDAyMTEyOS9nZGIvdGVzdHN1aXRlL2dkYi5jKysvb3ZlcmxvYWQuZXhwLn4xfglUdWUgSmFuICA4
IDAwOjM3OjQzIDIwMDIKLS0tIGdkYitkZWphZ251LTIwMDIxMTI5L2dkYi90ZXN0c3VpdGUvZ2Ri
LmMrKy9vdmVybG9hZC5leHAJV2VkIE1hciAyNiAyMjoxNDozOCAyMDAzCioqKioqKioqKioqKioq
KgoqKiogMTIwLDEyNSAqKioqCi0tLSAxMjAsMTU3IC0tLS0KICAgIH0KICAKICAKKyAjIFN1cHBv
c2UgdGhlIGFyY2hpdGVjdHVyZSB1c2VzIHRoZSBzdGFjayBwb2ludGVyIGFzIGEgZnJhbWUgcG9p
bnRlcgorICMgZm9yIGZ1bmN0aW9ucyB0aGF0IGRvbid0IHVzZSBhbGxvY2EsIGFuZCBtYXJrZXIx
IGlzIGEgZnJhbWVsZXNzCisgIyBmdW5jdGlvbi4gIEluIHRoaXMgY2FzZSwgR0RCIChhcyBvZiBO
b3YgMjAwMikgaXNuJ3QgYWJsZSB0bworICMgcmVjb2duaXplIHRoYXQsIGFmdGVyIHRoZSBtZXRo
b2QgaW52b2NhdGlvbiBoYXMgcmV0dXJuZWQsIGl0IHNob3VsZAorICMgc2VsZWN0IG1haW4ncyBm
cmFtZSwgbm90IG1hcmtlcjEncyBmcmFtZSAtLS0gdGhlaXIgZnJhbWUgcG9pbnRlcnMKKyAjIGFy
ZSB0aGUgc2FtZS4gIFNvIGFmdGVyIHRoZSBmaXJzdCBjYWxsLCBhbGwgdGhlIHN1YnNlcXVlbnQg
dGVzdHMKKyAjIGZhaWwgYmVjYXVzZSBmb29faW5zdGFuY2UxIGlzIGxvY2FsIHRvIG1haW4uCisg
IworICMgVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBidWcgdG8gZGV0ZWN0LCBidXQgd2UnZCByYXRo
ZXIgaXQgZGlkbid0CisgIyBwcmV2ZW50IHVzIGZyb20gcnVubmluZyBhbGwgdGhlIHN1YnNlcXVl
bnQgb3ZlcmxvYWRpbmcgdGVzdHMuICBTbworICMgY2hlY2sgdGhlIHNlbGVjdGVkIGZyYW1lIHJp
Z2h0IG5vdzsgaWYgaXQncyBtYXJrZXIxLCB0aGVuIHJlcG9ydCBhCisgIyBmYWlsdXJlLCAnZmlu
aXNoJyB0aGF0IGNhbGwgdG8gZ2V0IHRoYXQgZnJhbWVsZXNzIGZyYW1lIG9mZiB0aGUKKyAjIHN0
YWNrLCBhbmQgY29udGludWUgdGhlIHRlc3RzLgorIHNlbmRfZ2RiICJmcmFtZVxuIgorIGdkYl9l
eHBlY3QgeworICAgICAtcmUgIiMwICBtYXJrZXIxLiokZ2RiX3Byb21wdCAkIiB7CisgICAgICAg
ICBmYWlsICJyZS1zZWxlY3RlZCAnbWFpbicgZnJhbWUgYWZ0ZXIgaW5mZXJpb3IgbWV0aG9kIGNh
bGwiCisgICAgICAgICBnZGJfdGVzdCAiZmluaXNoIiAiLiptYWluLiphdCAuKm92ZXJsb2FkLmNj
OjdcWzc4XF0uKiIgXAorICAgICAgICAgICAgICAgICAiZmluaXNoIGNhbGwgdG8gbWFya2VyMSIK
KyAgICAgfQorICAgICAtcmUgIiMxICAoJGhleCBpbiApP21haW4uKiRnZGJfcHJvbXB0ICQiIHsK
KyAgICAgICAgIHBhc3MgInJlLXNlbGVjdGVkICdtYWluJyBmcmFtZSBhZnRlciBpbmZlcmlvciBt
ZXRob2QgY2FsbCIKKyAgICAgfQorICAgICAtcmUgIi4qJGdkYl9wcm9tcHQgJCIgeworICAgICAg
ICAgZmFpbCAicmUtc2VsZWN0ZWQgJ21haW4nIGZyYW1lIGFmdGVyIGluZmVyaW9yIG1ldGhvZCBj
YWxsIgorICAgICB9CisgICAgIHRpbWVvdXQgeworICAgICAgICAgZmFpbCAicmUtc2VsZWN0ZWQg
J21haW4nIGZyYW1lIGFmdGVyIGluZmVyaW9yIG1ldGhvZCBjYWxsICh0aW1lb3V0KSIKKyAgICAg
fQorIH0KKyAgICAgICAgIAorIAogIHNlbmRfZ2RiICJwcmludCBmb29faW5zdGFuY2UxLm92ZXJs
b2FkYXJncygxLCAyKVxuIgogIGdkYl9leHBlY3QgewogICAgICAtcmUgIi5cWzAtOVxdKiA9IDJc
clxuJGdkYl9wcm9tcHQgJCIgewo=


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]