Hi,

I noticed while doing something else in parse.c, something suspicous.
It happens that after preprocessor macros support went
in, parse.c:parse_exp_in_context got changed in a form that
introduced a bug here:

static struct expression *
parse_exp_in_context (char **stringptr, struct block *block, int comma, 
		      int void_context_p)
{
...
  if (!block)
    block = get_selected_block (&expression_context_pc);

   ^^^ if this returns a block, expression_context_pc contains
       an accurate pc.

  /* Fall back to using the current source static context, if any. */

  if (!block)
    {
      struct symtab_and_line cursal = get_current_source_symtab_and_line ();
      if (cursal.symtab)
	block = BLOCKVECTOR_BLOCK (BLOCKVECTOR (cursal.symtab), STATIC_BLOCK);
    }

  /* Save the context, if specified by caller, or found above. */

  if (block)
    {
      expression_context_block = block;
      expression_context_pc = BLOCK_START (block);

      ^^^ but here we're always overriding it with BLOCK_START.

    }

Talking about this with Jim Blandy, he explained it like so:

 "We want the exact PC because macros are scoped from one line to the
 next, not by block.  For example, we could have:

    {
      int foo;

      f ();
#define M slurgh;
      g ();
#undef M
      h ();
    }

 In this case, there will be only one lexical block covering the
 declaration of foo and all three statements, but we'd like to see the
 definition of M when we're stopped at the call to g, and not when
 we're stopped at the calls to f or h.  So we need to take a PC, find
 the source line and file, and then use that to decide whether any
 given macro is in scope."

Currently, "print M" when stopped at the g (); call above prints:
(gdb) print M
No symbol "M" in current context.

The attached patch fixes the issue, and adds a test to ensure
we don't regress again.

Tested on x86_64-unknown-linux-pc.

OK?

-- 
Pedro Alves