From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Jim Meyering <jim@meyering.net>
Cc: gdb-patches@sourceware.org, Corinna Vinschen <vinschen@redhat.com>
Subject: Re: rawhide's gdb segfaults, w/patch
Date: Fri, 09 Jan 2009 21:45:00 -0000 [thread overview]
Message-ID: <20090109214512.GA5851@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <87abag9pi1.fsf@rho.meyering.net>
Hi Jim,
thanks but your patch needed a second part. It is a regression from:
http://sourceware.org/ml/gdb-cvs/2008-04/msg00136.html
On Sun, 28 Dec 2008 18:30:14 +0100, Jim Meyering wrote:
> Here's an untested and quite possibly-wrong patch.
> I.e., if the warning should be given even when "thisfun" is NULL,
> it would have to be different.
I find it right as gdbarch_return_value_ftype even has a comment:
FUNCTYPE may be NULL in which case the return convention is computed based
only on VALTYPE.
This new argument and functype|func_type is only used in sh-tdep.c
http://sourceware.org/ml/gdb-patches/2008-04/msg00277.html
and even there it can be safely NULL.
This new argument and functype|func_type was added by
http://sourceware.org/ml/gdb-patches/2008-04/msg00276.html
I find just questionable whether the new testcase should be in
gdb.base/nodebug.exp or gdb.base/return*.exp but may be any way is OK.
Thanks,
Jan
gdb/
2009-01-09 Jim Meyering <meyering@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Avoid NULL dereference.
* stack.c (return_command): Guard use of SYMBOL_TYPE (thisfun).
New variable func_type.
gdb/testsuite/
2009-01-09 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/nodebug.exp (return from function with no debug info): New.
--- gdb/stack.c 3 Jan 2009 05:57:53 -0000 1.183
+++ gdb/stack.c 9 Jan 2009 20:30:25 -0000
@@ -1823,7 +1823,8 @@ return_command (char *retval_exp, int fr
is discarded, side effects such as "return i++" still
occur. */
return_value = NULL;
- else if (using_struct_return (SYMBOL_TYPE (thisfun), return_type))
+ else if (thisfun != NULL
+ && using_struct_return (SYMBOL_TYPE (thisfun), return_type))
{
query_prefix = "\
The location at which to store the function's return value is unknown.\n\
@@ -1856,10 +1857,12 @@ If you continue, the return value that y
{
struct type *return_type = value_type (return_value);
struct gdbarch *gdbarch = get_regcache_arch (get_current_regcache ());
- gdb_assert (gdbarch_return_value (gdbarch, SYMBOL_TYPE (thisfun),
- return_type, NULL, NULL, NULL)
+ struct type *func_type = thisfun == NULL ? NULL : SYMBOL_TYPE (thisfun);
+
+ gdb_assert (gdbarch_return_value (gdbarch, func_type, return_type, NULL,
+ NULL, NULL)
== RETURN_VALUE_REGISTER_CONVENTION);
- gdbarch_return_value (gdbarch, SYMBOL_TYPE (thisfun), return_type,
+ gdbarch_return_value (gdbarch, func_type, return_type,
get_current_regcache (), NULL /*read*/,
value_contents (return_value) /*write*/);
}
--- gdb/testsuite/gdb.base/nodebug.exp 3 Jan 2009 05:58:03 -0000 1.10
+++ gdb/testsuite/gdb.base/nodebug.exp 9 Jan 2009 20:30:26 -0000
@@ -215,5 +215,12 @@ if [runto inner] then {
if [runto middle] then {
gdb_test "backtrace 10" "#0.*middle.*#1.*top.*#2.*main.*" \
"backtrace from middle in nodebug.exp"
+
+ # Test return from a function with no debug info (symbol; still it may
+ # have a minimal-symbol). In gdb.base/return*.exp we would need to
+ # build a separate executable with no "debug" option.
+ gdb_test "return 0" "#0 .* top \\(.*" \
+ "return from function with no debug info" \
+ "Make selected stack frame return now\\? \\(y or n\\) " "y"
}
}
next prev parent reply other threads:[~2009-01-09 21:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-28 19:37 Jim Meyering
2009-01-09 21:45 ` Jan Kratochvil [this message]
2009-01-10 9:52 ` Jim Meyering
2009-01-18 19:04 ` Jim Meyering
2009-01-18 19:23 ` Jan Kratochvil
2009-02-02 18:44 ` Tom Tromey
2009-02-11 19:46 ` Jan Kratochvil
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=20090109214512.GA5851@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jim@meyering.net \
--cc=vinschen@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