From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Andrew Cagney Cc: David Taylor , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions Date: Fri, 30 Mar 2001 18:46:00 -0000 Message-id: References: <200103302149.QAA25007@texas.cygnus.com> <3AC515A0.30F2C587@cygnus.com> X-SW-Source: 2001-03/msg00572.html 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 *) > SYMBOL_DWARF2_LOC (var), > SYMBOL_TYPE (var)); > switch (SYMBOL_CLASS (var)) > { > case LOC_CONST: > > I would have expected something like: > > if (this symbol's location is computed dynamically) then > return var->compute_location_dynamically (frame); > > where that ``compute_location_dynamically'' was a function supplied by > dwarf2read.c. Why would dwarf2read.c supply it? It's not part of the symbol reader. It is the location of the symbol. Anything can fill in that particular field of the symbol structure. It's no different a location than LOC_CONST, LOC_REGPARM, etc. It just happens to be a bunch of operations that get evaluated, rather than 1 or 2 fixed ones. > > 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? > > Andrew -- I looked out my apartment window, and I saw a bird wearing sneakers and a button saying, "I ain't flying no where." I said, "What's your problem buddy?" He said, "I'm sick of this stuff -- winter here, summer there, winter here, summer there.