gdb_indent vs. dwarf2read

gdb_indent vs. dwarf2read

[Daniel Jacobowitz]

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'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, which matches the general style
in GDB; and comments like:
  1) foo
     bar
reindented to
  1) foo
  bar
.  Should we slavishly obey GNU indent in this, or should I reformat the
comments by hand before posting the reindentation patch?]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb_indent vs. dwarf2read

[Kevin Buettner]

On Jan 26, 10:11pm, Daniel Jacobowitz wrote:

> What do people think about adding "-T bfd -T asection" to gdb_indent.sh? 

I think it makes sense.

> [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, which matches the general style
> in GDB; and comments like:
>   1) foo
>      bar
> reindented to
>   1) foo
>   bar
> .  Should we slavishly obey GNU indent in this, or should I reformat the
> comments by hand before posting the reindentation patch?]

The problem with reformatting the comments (or anything else) by hand
is that someone else who runs GNU indent probably won't do the same
hand formatting.  If there's something you don't want indent to touch,
use /* *INDENT-OFF* */ (and later on, at the right point, /* *INDENT-ON* */.

Kevin

Re: gdb_indent vs. dwarf2read

[Andrew Cagney]

> 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....

> [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.

 > 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.

> .  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.

Andrew

Re: gdb_indent vs. dwarf2read

[Daniel Jacobowitz]

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

Re: gdb_indent vs. dwarf2read

[Andrew Cagney]

> .  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?

GDB's indentation is defined by the output of indent.  That one isn't 
open to negotation.

Please don't waste this lists time by re-visiting a dead issue.

Andrew

Re: gdb_indent vs. dwarf2read

[Daniel Jacobowitz]

On Mon, Jan 27, 2003 at 02:05:00PM -0500, Andrew Cagney wrote:
> >.  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?
> 
> GDB's indentation is defined by the output of indent.  That one isn't 
> open to negotation.
> 
> Please don't waste this lists time by re-visiting a dead issue.

Please don't shoot me in the head for asking an honest question.  It's
apparently been dead for longer than I've been on the GDB lists, and
the issue is not mentioned in MAINTAINERS or in the GDB internals
documentation.  Or even in a comment in gdb_indent.sh.  It wasn't
obvious to me that writing comments with indentation was against GDB's
formatting policies.

It should be documented, obviously.  It would be nice if there were
also a brief rationale, to prevent recurring arguments about what seems
at first glance to be a completely arbitrary decision.  I'm somewhat
unsettled by your response.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb_indent vs. dwarf2read

[Andrew Cagney]

> On Mon, Jan 27, 2003 at 02:05:00PM -0500, Andrew Cagney wrote:
> 
>> >.  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?
> 
>> 
>> GDB's indentation is defined by the output of indent.  That one isn't 
>> open to negotation.
>> 
>> Please don't waste this lists time by re-visiting a dead issue.
> 
> 
> Please don't shoot me in the head for asking an honest question.  It's
> apparently been dead for longer than I've been on the GDB lists, and
> the issue is not mentioned in MAINTAINERS or in the GDB internals
> documentation.  Or even in a comment in gdb_indent.sh.

The original indent occured ~99.

Search for `shebs indent' in the gdb@ mailing list.  There are a number 
of threads and that appears to find most of them.

Stan Shebs considered the comment problem but, in the end, went with 
straight indent with no arguments and used INDENT-ON / INDENT-OFF where 
he decided the output was too nasty.

gdb_indent.sh was added ~ November 2001.

 >  It wasn't
 > obvious to me that writing comments with indentation was against GDB's
 > formatting policies.

You can certainly format comments anyway you like.  Just don't be 
suprised if someone runs gdb_indent.sh over the file causing them to be 
reformatted.

> It should be documented, obviously.  It would be nice if there were
> also a brief rationale, to prevent recurring arguments about what seems
> at first glance to be a completely arbitrary decision.  I'm somewhat
> unsettled by your response.

PR gdb/712. PR gdb/698.

Indent's default mode (i.e., with no formattting arguments) should match 
the GNU coding style.  gdb_indent.sh runs indent in that mode so that 
it's indentation style matches the GNU coding style (-T isn't a 
formatting option).

Like I said, dead issue, lets get on to the real problems at hand.

Andrew

breakpoints

[jacques]

How do I set a breakpoint right after the last expression in a for loop? 
Thanks.
--Jacques

Breakpoints

[Satyavathi Malladi]

Hi,
  I have compiled a program using the gcc compiler with the options -g and
-ax (-ax is the  option to enable block profiling). I am debugging the
program using gdb-5.2 . I set a breakpoint at main. When the program hits
the breakpoint, I obtained the backtrace of the program.It was as follows:
(gdb) bt
#0  main () at ex7.c:7
#1  0x400a5316 in __libc_start_main (main=0x8048a34 <main>, argc=1,
ubp_av=0xbffff594, init=0x80487ac <_init>, fini=0x804a1d0 <_fini>,
rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbffff58c)
at ../sysdeps/generic/libc-start.c:129

Then I continued the program using the command "continue". Then the
breakpoint at main was hit again.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08048a50 in main () at ex7.c:7
Then when I tried to obtain the backtrace, I got the following output:
(gdb) bt
#0  0x08048a50 in main () at ex7.c:7
#1  0xbffff568 in ?? ()

Can someone help me figure out why this is happening.

Thanks,
Satya

Re: Breakpoints

[Mark Salter]

>>>>> Kevin Buettner writes:

> On Dec 22,  2:29pm, David Williams wrote:
>> Does GDB ever need to set more than one breakpoint when stepping through 
>> source code? I have not (as yet) seen this type of behaviour.

> Can the target do a singlestep in hardware or do you have to do
> software emulation?  If the latter, when you're stepping by machine
> instruction, you'd need two breakpoints on a conditional branch;
> one for the branch target, the other for the instruction after the
> branch.

Even in the latter case, the stub can evaluate the condition of the
branch to see which way its going to go.

--Mark

Re: Breakpoints

[J.T. Conklin]

>>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes:
David> Hi all, Does GDB ever need to set more than one breakpoint when
David> stepping through source code? I have not (as yet) seen this
David> type of behaviour.

I don't know.  It would be useful if GDB only needed one breakpoint.
Yours is not the only target with a single hardware breakpoint.

David> I have a stub that supports breakpoints in flash via hardware
David> facility but it can set only one breakpoint. If GDB requires
David> more than one at time then I am in trouble. My target is
David> 68EZ328 (68000 core, not CPU32, no BDM, has its own peculiar
David> emulation mode). My stub currently looks for attempts to write
David> trap #1 op-codes to program memory (FLASH) and then instead of
David> writing to program memory it sets a hardware breakpoint at the
David> address (thanks Stan for the suggestion).

It might be useful to support the remote protocol's 'Z'/'z' breakpoint
commands.  This eliminates the possibility that a memory write will be
confused with breakpoint insertion.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Wed Dec 22 16:34:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: protocol spec
Date: Wed, 22 Dec 1999 16:34:00 -0000
Message-id: <5mbt7i337b.fsf@jtc.redbacknetworks.com>
References: <Pine.SGI.3.95.991219200735.6636A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00544.html
Content-length: 1533

>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> IMHO, we have to resolve just a few key issues here one way
Quality> or other, before piling new operations into remote protocol.
Quality>
Quality> 1. Do we want the remote to support per thread software
Quality>    breakpoints ?

Absolutly.  At the very least, we don't want to preclude the target
debug agent from supporting per thread breakpoints (of any type).

The model I was thinking of when I originally proposed the breakpoint
extensions was that it would ultimately be up to the agent whether to
implement thread specific breakpoints.  GDB would make no assumptions
--- if a breakpoint fired, it would determine the thread od and would
continue target execution if a breakpoint wasn't set for that thread.

On target with a debug agent that doesn't handle thread specific
breakpoints, you might see a GDB<->debug agent dialog something like:

        -> Hg05
        <- OK
        -> Z0,XXXX,2
        <- OK
        -> c
        <- T05:PC=XXXX;thread=00
        -> c
        <- T05:PC=XXXX;thread=01
        -> c
        <- T05:PC=XXXX;thread=00
        -> c
        <- T05:PC=XXXX;thread=05

But on a system that supports thread specific breakpoints, you'd see
something like this:

        -> Hg05
        <- OK
        -> Z0,XXXX,2
        <- OK
        -> c
        <- T05:PC=XXXX;thread=05

This could be a substantial difference, especially when using low
bandwidth or high latency i/o channels.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Wed Dec 22 17:51:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Stan Shebs is leaving Cygnus
Date: Wed, 22 Dec 1999 17:51:00 -0000
Message-id: <199912230151.RAA24745@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00545.html
Content-length: 1522

Yes, I'm resigning from Cygnus; my last day in the office is tomorrow,
1999-12-23. Yes, this is rather sudden!  The reasons are a little
complicated and I don't want to "overshare" :-), so suffice it to say
that my personal stock situation makes it advisable for me not to be a
Cygnus employee when the Red Hat merger is completed.

The timing is somewhat unfortunate, because I'm still completely
enthusiastic about Cygnus, Red Hat, GDB, GNU, etc, and our little
community's future prospects look brighter than they ever have before.
In fact, once my financial situation allows, I would very much like to
go to work at Red Hat!

In the meantime, I intend to continue working on GDB and to continue
maintaining parts of it, while spreading more of my tasks around to
other people.  RMS has a steering committee proposal that he should be
posting soon, and that will be a good first step in this direction.
The committee can then decide whether it would prefer GDB to keep the
status quo of a single maintainer coordinating sub-maintainers, or to
be more anarchic with no single technical decisionmaker, a la GCC.  In
any case, I'm still planning to serve on this committee.

My temporary mail address will be shebs@nabeng.com, at least until I
pick a cool domain name for my new consulting business. :-) Also, from
25 Dec to 8 Jan, I'm going to be savoring margaritas in the tropics,
and incommunicado during the entire time.  After that, however, I will
be available for tools consulting and contract work.

								Stan
From ovidiu@cup.hp.com Wed Dec 22 18:51:00 1999
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Stan Shebs is leaving Cygnus 
Date: Wed, 22 Dec 1999 18:51:00 -0000
Message-id: <199912230249.SAA09138@orion.rgv.hp.com>
References: <199912230151.RAA24745@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00546.html
Content-length: 1957

Hi Stan,

I'm terribly sorry to hear this! I was just thinking that you guys at Cygnus
must be really lucky with RedHat these days, given the high stock price it has.
However it appears it's not quite true :-(.

I wish you best of luck in your new enterprise!

Greetings and Merry Christmas,
Ovidiu

On Wed, 22 Dec 1999 17:51:15 -0800, Stan Shebs <shebs@cygnus.com> wrote:

> Yes, I'm resigning from Cygnus; my last day in the office is tomorrow,
> 1999-12-23. Yes, this is rather sudden!  The reasons are a little
> complicated and I don't want to "overshare" :-), so suffice it to say
> that my personal stock situation makes it advisable for me not to be a
> Cygnus employee when the Red Hat merger is completed.
> 
> The timing is somewhat unfortunate, because I'm still completely
> enthusiastic about Cygnus, Red Hat, GDB, GNU, etc, and our little
> community's future prospects look brighter than they ever have before.
> In fact, once my financial situation allows, I would very much like to
> go to work at Red Hat!
> 
> In the meantime, I intend to continue working on GDB and to continue
> maintaining parts of it, while spreading more of my tasks around to
> other people.  RMS has a steering committee proposal that he should be
> posting soon, and that will be a good first step in this direction.
> The committee can then decide whether it would prefer GDB to keep the
> status quo of a single maintainer coordinating sub-maintainers, or to
> be more anarchic with no single technical decisionmaker, a la GCC.  In
> any case, I'm still planning to serve on this committee.
> 
> My temporary mail address will be shebs@nabeng.com, at least until I
> pick a cool domain name for my new consulting business. :-) Also, from
> 25 Dec to 8 Jan, I'm going to be savoring margaritas in the tropics,
> and incommunicado during the entire time.  After that, however, I will
> be available for tools consulting and contract work.
> 
> 								Stan
> 

RE: Breakpoints

[David Williams]

My question is still does GDB need to set more than one breakpoint when 
stepping through source? Thinking about it a little more GDB should have 
all of the information available to decide whether a branch will occur. It 
has the current value of all the registers (esp CCR) so it can work it out 
- the real question is does it use this information?

Dave.

----------
From: 	Mark Salter[SMTP:msalter@cygnus.com]
Sent: 	Thursday, December 23, 1999 2:09 AM
To: 	kevinb@cygnus.com
Cc: 	davidwilliams@ozemail.com.au; gdb@sourceware.cygnus.com
Subject: 	Re: Breakpoints

>>>>> Kevin Buettner writes:

> On Dec 22,  2:29pm, David Williams wrote:
>> Does GDB ever need to set more than one breakpoint when stepping through 
>> source code? I have not (as yet) seen this type of behaviour.

> Can the target do a singlestep in hardware or do you have to do
> software emulation?  If the latter, when you're stepping by machine
> instruction, you'd need two breakpoints on a conditional branch;
> one for the branch target, the other for the instruction after the
> branch.

Even in the latter case, the stub can evaluate the condition of the
branch to see which way its going to go.

--Mark