Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb@sourceware.org
Subject: change of behavior in block_innermost_frame... ("inline" patch?)
Date: Fri, 28 Aug 2009 15:35:00 -0000	[thread overview]
Message-ID: <20090828151710.GI6540@adacore.com> (raw)

Hi Daniel,

I was trying to resync AdaCore's patches vs the current HEAD sources
at the FSF, and I noticed that there was a slight change in behavior
inside block_innermost_frame. I wanted to have your thoughts on this.

The situation we have is that we have a nested procedure from which
we're trying to print the value of a variable defined in the outer
procedure. In other words:

   procedure Test_Nesting is
      N: Integer;
      procedure Inner1 (Y: INTEGER) is
      begin
         if (Y < N) then
            Inner1 (Y * 2);
         else
            --gdb: break nesting.adb:15
            --gdb: cont
            Put (Integer'Image (Y));    -- BREAK

We stopped at the last quoted line ("BREAK"), and tried to print
the value of N. Normally, what would happen is that value_of_variable
calls block_innermost_frame to find the frame where this variable
is defined (in my case frame #6), and then pass that frame to
read_var_value for actual reading. What happens in that case is
that we changed the logic of block_innermost_frame to use the
block.c::contained_in function to match the frame to our given block,
which relies on superblock relationship. As a result, in my case
above, block_innermost_frame now returns frame 0 (which corresponds
to procedure Inner1), because the corresponding block is in fact
contained in the block I'm looking for. This is of course the wrong
frame to be using in order to print variable N :-(.

I was wondering what was the reason for the change. I would like to fix
the issue while at the same time not causing a regression... Any additional
thoughts?

Thanks,
-- 
Joel


             reply	other threads:[~2009-08-28 15:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-28 15:35 Joel Brobecker [this message]
2009-08-29 14:00 ` Daniel Jacobowitz

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=20090828151710.GI6540@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    /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