Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: vgoyal@in.ibm.com
Cc: gdb@sources.redhat.com, dan@debian.org, fastboot@lists.osdl.org,
	linux-kernel@vger.kernel.org, akpm@osdl.org, bunk@stusta.de,
	alexn@dsv.su.se
Subject: Re: [Fastboot] Re: [-mm patch] i386: enable REGPARM by default
Date: Tue, 28 Jun 2005 20:00:00 -0000	[thread overview]
Message-ID: <200506281959.j5SJxaeM022138@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20050628112412.GB5652@in.ibm.com> (message from Vivek Goyal on Tue, 28 Jun 2005 16:54:12 +0530)

   Date: Tue, 28 Jun 2005 16:54:12 +0530
   From: Vivek Goyal <vgoyal@in.ibm.com>

   > Thanks. Any idea what might be amiss with my case where I am not seeing 
   > proper function parameter values while analyzing kdump generated crash
   > dump with gdb. I am using following gdb and gcc versions.
   > 
   > GNU gdb Red Hat Linux (6.1post-1.20040607.62rh)
   > gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
   > 

   Some more info. I dumped the stack contents and it seems that stack is fine 
   and parameters are intact on stack. So now it seems to be a matter of 
   how gdb is interpreting the stack contents. Any guess, what the problem is?

I'd say the problem is with a user building stuff with non-standard
"optimizations", probably even stripping his executable, and expecting
to be able to debug the result.

   Why func2() and func1() are not showing right parameter values. 

Repeating what Daniel said before, by using "regparm", function
arguments are now passed in registers instead of on the stack.  It's
extremely unlikely that these function arguments will stay in those
registers for ever, especially since you've only got a handfull of
them on the i386.  So eventually they will be moved to some other
register or, more likely, to memory.  If the compiler doesn't tell gdb
about it, gdb will still think the value is in the register, and
display whatever what's there now, which is likely to be the wrong
value.  There are two ways the compiler can tell gdb where things are:

1. By explicitly specifying the new location.  Both DWARF 2 and stabs
   debugging formats can do this, but AFAIK, GCC won't do this if a
   register is spilled to the stack.

2. By specifying where registers are saved.  Only DWARF 2 can do this.

We've seen cases where the information generated by GCC for 1 or 2 is
either incomplete or wrong.  There also have been cases where GDB
didn't interpret that information correctly.  And then some people
tend to remove some of the debug information by stripping their code
or using broken linker scripts. You'll need to find out where the
problem is, but my bet is that its's a problem with GCC since you make
it generate non-standard code.

Oh, by the way, don't expect gdb to be able to call "regparm"
functions either.

Mark


  reply	other threads:[~2005-06-28 20:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050624200916.GJ6656@stusta.de>
     [not found] ` <20050624132826.4cdfb63c.akpm@osdl.org>
2005-06-27 13:30   ` Vivek Goyal
2005-06-27 14:00     ` Daniel Jacobowitz
2005-06-28  4:51       ` Vivek Goyal
2005-06-28 11:24         ` Vivek Goyal
2005-06-28 20:00           ` Mark Kettenis [this message]
2005-06-29  8:35             ` Vivek Goyal
2005-06-29 10:08               ` Mark Kettenis
2005-06-29 11:47                 ` Vivek Goyal

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=200506281959.j5SJxaeM022138@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=akpm@osdl.org \
    --cc=alexn@dsv.su.se \
    --cc=bunk@stusta.de \
    --cc=dan@debian.org \
    --cc=fastboot@lists.osdl.org \
    --cc=gdb@sources.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@in.ibm.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