This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions


    Date: Fri, 30 Mar 2001 14:10:46 -0500 (EST)
    From: Daniel Berlin <dberlin@redhat.com>

    This patch adds a place in the symbol structure to store the dwarf2
    location (an upcoming dwarf2read huge rewrite patch uses it), an
    evaluation maachine to findvar.c, and has read_var_value use the dwarf2
    location if it's available.

    NOte that in struct d2_location, in the symtab.h patch, that framlocdesc
    cannot be unioned with locdesc, because the symbol providing the frame
    location description  usually has it's own real location.

    Currently, because GDB makes no use of the frame unwind info, etc, I
    evaluate the frame pointer location expression for whatever is providing
    it for the thing we are trying to evaluate, rather than rely what GDB
    tells us the frame pointer is.

I have read that "sentence" multiple times and I still  don't know what
you are trying to say.  Sorry.

    Yes, it's currently pointless to do this,  it's just future proofing, and
    what we are supposed to do, anyway.

    This patch will have no effect whatosever without the dwarf2read.c
    rewrite, but it won't break anything, neither, so i sepereated it out and
    am submitting it now.
    --Dan
    2001-03-30  Daniel Berlin  <dberlin@redhat.com>

	    * symtab.h (address_class): Add LOC_DWARF2_EXPRESSION.
	    (struct symbol): Add struct d2_location to store dwarf2
	    location expressions.
	    (SYMBOL_DWARF2_LOCATION, SYMBOL_DWARF2_FRAME_LOCATION): New macros.

	    * findvar.c (read_leb128): New function, read leb128 data from a
	    buffer.

I don't know what leb128 data is (and I doubt that I'm alone).  I
suspect that it is something dwarf of dwarf2 specific and that this
function really belongs in another file (dwarf2read.c maybe?).  At a
minimum there should probably be some sort of explanatory comment.

	    (evaluate_dwarf2_locdesc): New function, evaluate a given
	    dwarf2 location description.

This is a very dwarf2 specific change to findvar.c.  What happens if
something other than dwarf2 is in use?

Also, should these functions be in here?  In dwarf2read.c?  Or in a
new file (dwarf2eval.c?)?

	    (read_var_value): Use the dwarf2 location expression if it's available.

How do you know that the location expression is NULL when you haven't
set it -- in particular, what's to prevent it from having garbage in
it?

And is it likely that some other symbol reader would someday want a
similar hook?  For example, what about dwarf1?  Or is dwarf2 likely to
be the only one?


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