headers
Chris Moller | 2 Feb 2010 23:12
Picon
Favicon

patch for pr9067

Tom

I just sent $subject to gdb-patches.  Turns out it was simultaneously 
more complex and simpler than we both thought:  You can't just blindly 
inhibit multiple printings of static members.  Sometimes it's 
legitimate, like when they legitimately appear multiple times, possibly 
on different paths through the tree.  The simple side is that after I'd 
finished writing a tree-path-aware fix for the bug, while I was testing 
it, I noticed that someone had already stuck in an attempted fix, using 
obstacks, but had screwed up their use.  Not that I'm a big fan of 
obstacks, but on the least-tinkering-possible principle, I scrapped my 
new stuff and fixed the obstacks.

Chris
Permalink | Reply | 3 comments |
headers
Tom Tromey | 3 Feb 2010 00:28
Picon
Favicon

Re: patch for pr9067

>>>>> "Chris" == Chris Moller <cmoller@...> writes:

Chris> I just sent $subject to gdb-patches.

Thanks.

Chris> Turns out it was simultaneously more complex and simpler than we
Chris> both thought: You can't just blindly inhibit multiple printings
Chris> of static members.  Sometimes it's legitimate, like when they
Chris> legitimately appear multiple times, possibly on different paths
Chris> through the tree.

I didn't see this in the test case you sent.
Could you add it?

Chris> Not that I'm a big fan of obstacks, but on the
Chris> least-tinkering-possible principle, I scrapped my new stuff and
Chris> fixed the obstacks.

Yeah, that's the right thing to do.

Tom
Permalink | Reply | 2 comments |
headers
Jan Kratochvil | 3 Feb 2010 01:10
Picon
Favicon

[fortran-module] [commit] Fix a regression on setting breakpoint at toplevel symbols

f5c7672a52316155bc3367cbc2f0e7db22523634

https://bugzilla.redhat.com/show_bug.cgi?id=559291

gdb/
2010-02-03  Jan Kratochvil  <jan.kratochvil@...>
	    David Moore <david.moore@...>
	* f-lang.c (f_lookup_symbol_nonlocal): Always fallback on
	basic_lookup_symbol_nonlocal.

gdb/testsuite/
2010-02-03  Jan Kratochvil  <jan.kratochvil@...>
	* gdb.fortran/module.exp (show language, setting breakpoint at module):
	New.
	* gdb.fortran/module.f90: New statement program module.
---
 gdb/f-lang.c                         |   43 +++++++++++++++++----------------
 gdb/testsuite/gdb.fortran/module.exp |   10 ++++++++
 gdb/testsuite/gdb.fortran/module.f90 |    2 +
 3 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/gdb/f-lang.c b/gdb/f-lang.c
index 79b46d2..7656fd2 100644
--- a/gdb/f-lang.c
+++ b/gdb/f-lang.c
 <at>  <at>  -320,34 +320,35  <at>  <at>  f_lookup_symbol_nonlocal (const char *name,
 			  const struct block *block,
 			  const domain_enum domain)
 {
-  struct fortran_using *use;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Moller | 3 Feb 2010 03:25
Picon
Favicon

Re: patch for pr9067

On 02/02/10 18:28, Tom Tromey wrote:
>>>>>> "Chris" == Chris Moller<cmoller@...>  writes:
>>>>>>              
>
> Chris>  I just sent $subject to gdb-patches.
>
> Thanks.
>
> Chris>  Turns out it was simultaneously more complex and simpler than we
> Chris>  both thought: You can't just blindly inhibit multiple printings
> Chris>  of static members.  Sometimes it's legitimate, like when they
> Chris>  legitimately appear multiple times, possibly on different paths
> Chris>  through the tree.
>
> I didn't see this in the test case you sent.
> Could you add it?
>    

Sure, I can add it, but there are a handful of existing test cases that 
already cover that circumstance--I found them the hard way when my 
simplistic first-pas "fix" kept filtering out legitimate instances.

> Chris>  Not that I'm a big fan of obstacks, but on the
> Chris>  least-tinkering-possible principle, I scrapped my new stuff and
> Chris>  fixed the obstacks.
>
> Yeah, that's the right thing to do.
>
> Tom
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Tromey | 3 Feb 2010 21:04
Picon
Favicon

Re: patch for pr9067

Chris> Sure, I can add it, but there are a handful of existing test cases
Chris> that already cover that circumstance--I found them the hard way when
Chris> my simplistic first-pas "fix" kept filtering out legitimate instances.

If it is triggered by the existing test suite, then that is good enough,
thanks.

Tom
Permalink | Reply | 0 comments |
headers
Chris Moller | 3 Feb 2010 22:52
Picon
Favicon

PR 11067

On 02/03/10 13:33, Tom Tromey wrote:
> Then how about http://sourceware.org/bugzilla/show_bug.cgi?id=11067 ?
> I just happened to run across this the other day; if it doesn't suit, I
> can dig through bugzilla and find something else.
>    

The enhancement req reads

> When I print a variable, printing the symbolic name for its value is right, but
> when I print the symbolic name, gdb should print its numeric value instead (or
> in addition).
>    

The simple fix is to always print both the symbolic name and the decimal 
value:

> (gdb) p e
> $1 = Val1 (= 56)
> (gdb) p Val1
> $2 = Val1 (= 56)
> (gdb)

That's a one-line change in c-valprint.c.  Trying to differentiate 
between those two cases looks like it would be significantly more difficult.

Would the one-line change do?  Or does the fix need to do exactly what 
the request says?

Chris
(Continue reading)

Permalink | Reply | 14 comments |
headers
Roland McGrath | 3 Feb 2010 23:42
Picon
Favicon

Re: PR 11067

> The simple fix is to always print both the symbolic name and the decimal 
> value:
> 
> > (gdb) p e
> > $1 = Val1 (= 56)
> > (gdb) p Val1
> > $2 = Val1 (= 56)
> > (gdb)

I think it should use a format consistent with p/c, e.g.:

(gdb) p 'a'
$1 = 97 'a'
(gdb) p ENUM1
$2 = (enum frobozz) 1 ENUM1
(gdb)

Thanks,
Roland
Permalink | Reply | 12 comments |
headers
Tom Tromey | 3 Feb 2010 23:47
Picon
Favicon

Re: PR 11067

>>>>> "Chris" == Chris Moller <cmoller@...> writes:

Chris> The simple fix is to always print both the symbolic name and the
Chris> decimal value:

>> (gdb) p e
>> $1 = Val1 (= 56)
>> (gdb) p Val1
>> $2 = Val1 (= 56)
>> (gdb)

Chris> That's a one-line change in c-valprint.c.  Trying to differentiate
Chris> between those two cases looks like it would be significantly more
Chris> difficult.

Chris> Would the one-line change do?  Or does the fix need to do exactly
Chris> what the request says?

The one-line fix is fine.

Tom
Permalink | Reply | 0 comments |
headers
Tom Tromey | 3 Feb 2010 23:48
Picon
Favicon

Re: PR 11067

>>>>> "Roland" == Roland McGrath <roland@...> writes:

Roland> I think it should use a format consistent with p/c, e.g.:
Roland> (gdb) p 'a'
Roland> $1 = 97 'a'
Roland> (gdb) p ENUM1
Roland> $2 = (enum frobozz) 1 ENUM1

Works for me.  Chris, please do it this way, thanks.

Tom
Permalink | Reply | 11 comments |
headers
Daniel Jacobowitz | 4 Feb 2010 00:14

Re: PR 11067

On Wed, Feb 03, 2010 at 03:48:20PM -0700, Tom Tromey wrote:
> >>>>> "Roland" == Roland McGrath <roland@...> writes:
> 
> Roland> I think it should use a format consistent with p/c, e.g.:
> Roland> (gdb) p 'a'
> Roland> $1 = 97 'a'
> Roland> (gdb) p ENUM1
> Roland> $2 = (enum frobozz) 1 ENUM1
> 
> Works for me.  Chris, please do it this way, thanks.

FWIW, we've had trouble in the past with the 97 'a' output, because
you get something out that you can't paste back in (not a valid
expression).  I know I did when working on C++ template value
parameters, but that's a special case.  More importantely, I believe
MI frontends had some trouble.

Roland's example is unintuitive to me since "1 ENUM1" just makes me
think "what is that?  it's not C, how are those two things related?".
The closest C language version would be "ENUM1 = 1".

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 9 comments |

Gmane