From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Berlin Cc: David Taylor , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions Date: Fri, 06 Apr 2001 12:02:00 -0000 Message-id: <3ACE12CA.E6176DDD@cygnus.com> References: <200103302149.QAA25007@texas.cygnus.com> <3AC515A0.30F2C587@cygnus.com> X-SW-Source: 2001-04/msg00072.html Daniel Berlin wrote: > > Andrew Cagney writes: > > > > So the code doesn't belong in dwarf2read.c. dwarf2read.c is a symbol > > > reader. dwarf2 location expressions are a way of describing variable > > > locations. The other code to process the current gdb address > > > classes/locations is in findvar.c, so that's where i put it. > > > > No. > > > > if (frame == NULL) > > frame = selected_frame; > > ! if (SYMBOL_DWARF2_LOC (var) != NULL) > > ! return evaluate_dwarf2_locdesc (var, frame, (struct dwarf_block *) Some code, somewhere must be setting SYMBOL_DWARF2_LOC (var). At a guess that code is either in dwarf2read.c or in a file using information obtained from dwarf2read.c. If SYMBOL_DWARF2_LOC() was replaced by a more generic method then, I'd expect that method to live in dwarf2read.c since it would be dwarf2read.c creating a type that contained that method. > > For this starts to make sense, I suspect it needs to be given some > > additional context - namely where in dwarf2read.c things are also going > > to be changed. > > Make sense? > In what way? It might help explain how this patch ties in to the rest of GDB. enjoy, Andrew