This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Using addrmaps for blocks


Back in October, when I first posted the patch to support
discontiguous lexical blocks in GDB, Joel asked:

  Why do we keep the two parallel approaches to blocks? Could we
  simply only use your map and get rid of the old structure?

I'd forgotten why, but I looked into it again this weekend, and it's
actually pretty obvious: there are many, many uses of BLOCK_START and
BLOCK_END throughout GDB, for a number of different purposes.

- We check a symtab's global block's limits to see if an address falls
  in that symtab.

- There is (was?) a bug where block_for_pc / find_pc_function would
  return the wrong function.  For reasons unclear to me, this gets
  checked and corrected separately in alpha-mdebug-tdep.c, stack.c,
  f-valprint.c, and possibly other places, instead of just making the
  fundamental lookup functions do the checks themselves.

- When we ask for the 'value' of a LOC_BLOCK symbol, that has always
  been the block's start.  I think we always use this for functions.

... and there are other cases I didn't get to.

Now, each of these cases is suspicious, because the fact is that
lexical blocks, compilation units, and everything else are not
contiguous, and just about anything that relies on BLOCK_START /
BLOCK_END is probably assuming that they are.  So there's substantial
cleanup needed here before we can get rid of them.  (I haven't gotten
to Jan's discontiguous partial symbol table changes yet, but I imagine
that's something along these lines.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]