Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@ges.redhat.com>
To: jimb@redhat.com
Cc: Daniel Berlin <dberlin@dberlin.org>, gdb-patches@sources.redhat.com
Subject: Re: [RFA]: dwarf2expr.[ch]
Date: Mon, 08 Jul 2002 21:12:00 -0000	[thread overview]
Message-ID: <3D2A5D2C.5040506@ges.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0207081941190.31676-100000@dberlin.org>

Jim,

Is it possible to simplify some of this.  For instance:

> +   void (*error) (const char *fmt, ...);

In GDB, the function error() has well understood semantics - no return, 
long jump, fprintf parameter checking, .....  Why not use error() 
directly?  Failing that, the function probably wants to be marked up 
with NORETURN and a printf attribute.

> + 
> +   /* If it has a location expression for fbreg, record it.  
> +      Since not all symbols use location expressions exclusively yet,
> +      we still need to decode it above. */
> +   if (attr)
> +     {
> +       baton = obstack_alloc (&objfile->symbol_obstack, sizeof (struct locexpr_baton));
> +       baton->sym = new->name;
> +       baton->obj = objfile;
> +       memcpy (&baton->locexpr, DW_BLOCK (attr), sizeof (struct dwarf_block));
> +       SYMBOL_LOCATION_FUNCS (new->name) = &locexpr_funcs;
> +       SYMBOL_LOCATION_BATON (new->name) = baton;
> +     }
> + 

Is there also a way of implementing these objects such that they check, 
at compile time, a match between initialized members and those that 
require assignment?  Perhaphs a memset(0) will be easiest.

I suspect, for instance, you'll need to add a thread_local_storgage() 
method pretty soon :-)

Andrew


  parent reply	other threads:[~2002-07-09  3:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-08 16:48 Daniel Berlin
2002-07-08 20:20 ` Andrew Cagney
2002-07-08 20:49   ` Daniel Berlin
2002-07-08 21:12 ` Andrew Cagney [this message]
2002-07-09 15:21   ` Jim Blandy
2002-07-10  9:05     ` Andrew Cagney
2002-07-09 15:10 ` Jim Blandy
2002-07-09 16:00   ` Daniel Berlin
2002-07-10 11:18   ` Daniel Berlin
2002-07-10 12:48     ` Jim Blandy
2002-07-10 13:27       ` Daniel Berlin
2002-07-10 16:15         ` Jim Blandy

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=3D2A5D2C.5040506@ges.redhat.com \
    --to=ac131313@ges.redhat.com \
    --cc=dberlin@dberlin.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@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