From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: gdb_indent vs. dwarf2read
Date: Mon, 27 Jan 2003 17:43:00 -0000 [thread overview]
Message-ID: <20030127174346.GA23136@nevyn.them.org> (raw)
In-Reply-To: <3E356CAD.1000306@redhat.com>
On Mon, Jan 27, 2003 at 12:30:21PM -0500, Andrew Cagney wrote:
> >What do people think about adding "-T bfd -T asection" to gdb_indent.sh?
> >That's the majority style in current GDB, and we do it for some other
> >similar types.
>
> I thought they were already....
Nope. We scan _our_ headers, but not BFD's. We could scan all of
BFD's headers in gdb_indent.sh, but I suspect it's not worth it.
> >[I'd like to re-indent dwarf2read.c, so I was looking over the results of
> >gdb_indent.sh on it before posting the patch. Other churn: structs moved
> >from two spaces indented to the left column
>
> Structs should not be indented two spaces.
>
> There was one release of indent that did the two space struct. GDB,
> unfortunatly, happened to do its jumbo re-indent using that version.
> Ever since then, re-indents have been `fixing' this foobar.
Ah OK, that, makes sense.
> > which matches the general style
> >in GDB; and comments like:
> > 1) foo
> > bar
> >reindented to
> > 1) foo
> > bar
>
> Can you give a real example? It might be a bug. There is also the
> no-indent comment mechanism for comments that really should not be
> re-indented.
Here's the first one in the file:
/* We use dwarf2_tmp_obstack for objects that don't need to survive
the partial symbol scan, like attribute values.
We could reduce our peak memory consumption during partial symbol
table construction by freeing stuff from this obstack more often
--- say, after processing each compilation unit, or each die ---
but it turns out that this saves almost nothing. For an
executable with 11Mb of Dwarf 2 data, I found about 64k allocated
on dwarf2_tmp_obstack. Some investigation showed:
1) 69% of the attributes used forms DW_FORM_addr, DW_FORM_data*,
DW_FORM_flag, DW_FORM_[su]data, and DW_FORM_ref*. These are
all fixed-length values not requiring dynamic allocation.
The indented block is reflowed to something like:
1) 69% of the attributes used forms DW_FORM_addr, DW_FORM_data*,
DW_FORM_flag, DW_FORM_[su]data, and DW_FORM_ref*. These are
all fixed-length values not requiring dynamic allocation.
I personally wish indent didn't do this; I write this kind of comment.
But at the same time it's useful that it reflows text in comments,
especially since I edit in a >80 column terminal.
> >. Should we slavishly obey GNU indent in this, or should I reformat the
> >comments by hand before posting the reindentation patch?]
>
> GDB's indentation is defined by the output of indent. That one isn't
> open to negotation.
OK; but if people prefer to write formatted comments, we could specify
indent options, couldn't we? Or are we defined by the decisions of the
Indent maintainers?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-01-27 17:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-27 3:10 Daniel Jacobowitz
2003-01-27 17:11 ` Kevin Buettner
2003-01-27 17:30 ` Andrew Cagney
2003-01-27 17:43 ` Daniel Jacobowitz [this message]
2003-01-27 19:05 ` Andrew Cagney
2003-01-27 19:17 ` Daniel Jacobowitz
2003-01-27 20:44 ` Andrew Cagney
2003-01-27 20:02 ` breakpoints jacques
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=20030127174346.GA23136@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@redhat.com \
--cc=gdb@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