From: Elena Zannoni <ezannoni@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa:symtab] SYMBOL_LOCATION_FUNCS -> SYMBOL_OPS
Date: Fri, 23 Jan 2004 15:49:00 -0000 [thread overview]
Message-ID: <16401.16897.417048.555558@localhost.redhat.com> (raw)
In-Reply-To: <3FB91365.8050809@redhat.com>
Andrew Cagney writes:
> > Hello,
> >
> > This patch generalizes the per-symbol location_funcs, replacing them with a symbol_ops vector (the contents are unchanged). The patch doesn't change the size of the symbol.
> >
> > As the comment hints:
> >
> > + /* NOTE: cagney/2003-11-02: The fields "aclass" and "ops" contain
> > + overlaping information. Since GDB has only a small finite number
> > + of symbol classes it should be possible to merge the two fields
> > + into a single ops-table "index". Each entry providing both the
> > + "ops" and the "aclass" values. Doing that would shave 32 bits
> > + off every symbol. */
> >
> > The patch sets us up for a more significant change - merge "ops" and "aclass" - and hence eliminates 32 bits (or 20%) of each symbol. I should note that right now the details of the merge are "left as an exercise for the reader".
> >
> > ok?
>
> Ping? I revised the comment thus:
>
> /* NOTE: cagney/2003-11-02: The fields "aclass" and "ops" contain
> overlapping information. By creating a per-aclass ops vector, or
> using the aclass as an index into an ops table, the aclass and
> ops fields can be merged. The latter, for instance, would shave
> 32-bits from each symbol (relative to a symbol lookup, any table
> index overhead would be in the noise). */
>
Ok.
elena
> Andrew
>
> 2003-11-08 Andrew Cagney <cagney@redhat.com>
>
> * dwarf2loc.c (dwarf_expr_frame_base): Use SYMBOL_OPS instead of
> SYMBOL_LOCATION_FUNCS
> (dwarf2_loclist_funcs, dwarf2_locexpr_funcs): Change type to
> "struct symbol_ops".
> * dwarf2loc.h (dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Change
> type to "struct symbol_ops".
> * dwarf2read.c (dwarf2_symbol_mark_computed): Set SYMBOL_OPS
> intead of SYMBOL_LOCATION_FUNCS.
> * ax-gdb.c (gen_var_ref): Ditto for "tracepoint_var_ref".
> * printcmd.c (address_info): Ditto for "describe_location".
> * findvar.c (symbol_read_needs_frame): Call "read_needs_frame"
> when available. Assert requirement when LOC_COMPUTED or
> LOC_COMPUTED_ARG.
> (read_var_value): Ditto for "read_variable".
> * symtab.h (struct symbol_ops): Rename "struct location_funcs".
> (struct symbol): Replace ".aux_value.loc.funcs" and
> ".aux_value.loc.baton" with ".ops" and ".aux_value.ptr".
> (SYMBOL_OBJFILE): Delete macro.
> (SYMBOL_LOCATION_FUNCS): Delete macro.
> (SYMBOL_LOCATION_BATON): Update.
next prev parent reply other threads:[~2004-01-23 15:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-08 20:36 Andrew Cagney
2003-11-08 21:31 ` Daniel Jacobowitz
2003-11-09 13:54 ` Andrew Cagney
2003-11-17 18:28 ` Andrew Cagney
2004-01-23 15:49 ` Elena Zannoni [this message]
2004-01-26 20:35 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16401.16897.417048.555558@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox