Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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"
     }
 }


  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