[Bug c++/19274] New: ptype can't find type in libxul.so

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

Bug ID: 19274
Summary: ptype can't find type in libxul.so
Product: gdb
Version: unknown
Status: NEW
Severity: normal
Priority: P2
Component: c++
Assignee: unassigned at sourceware dot org
Reporter: tromey at sourceware dot org
Target Milestone: ---

I am trying to inspect a certain type in libxul.so.
I'm using a gdb based off of today's git master.

A simple attempt fails like this:

(gdb) ptype mozilla::net::HttpChannelChild
No type "net" within class or namespace "mozilla".

However, that type really does exist:

(gdb) info types mozilla::net::HttpChannelChild
All types matching regular expression "mozilla::net::HttpChannelChild":
[...]
File ../../../dist/include/mozilla/net/HttpChannelChild.h:
mozilla::net::HttpChannelChild;


Trying with a leading "::" gives an error:

(gdb) ptype ::mozilla::net::HttpChannelChild
A syntax error in expression, near `mozilla::net::HttpChannelChild'.

[sbergman at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

Stephan Bergmann <sbergman at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |sbergman at redhat dot com
See Also| |https://sourceware.org/bugz
| |illa/show_bug.cgi?id=22968

[keiths at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

Keith Seitz <keiths at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |keiths at redhat dot com

--- Comment #1 from Keith Seitz <keiths at redhat dot com> ---
I ran across this bug while working on 22968. Using a snapshot from today, this
appears to be working:

(gdb) ptype mozilla::net::HttpChannelChild
type = class mozilla::net::HttpChannelChild : public
mozilla::net::PHttpChannelChild, public mozilla::net::HttpBaseChannel
, public mozilla::net::HttpAsyncAborter<mozilla::net::HttpChannelChild>
, public nsICacheInfoChannel, public nsIProxiedChannel
, public nsIApplicationCacheChannel
, public nsIAsyncVerifyRedirectCallback
, public nsIAssociatedContentSecurity, public nsIChildChannel
, public nsIHttpChannelChild, public nsIDivertableChannel
, public nsIThreadRetargetableRequest, public
mozilla::net::NeckoTargetHolder {
private:
nsCOMPtr<nsISupports> mCacheKey;
nsCOMPtr<nsIChildChannel> mRedirectChannelChild;
RefPtr<mozilla::net::InterceptStreamListener> mInterceptListener;
nsCOMPtr<nsIStreamListener> mInterceptedRedirectListener;
nsCOMPtr<nsISupports> mInterceptedRedirectContext;
mozilla::net::RequestHeaderTuples mClientSetRequestHeaders;
RefPtr<nsInputStreamPump> mSynthesizedResponsePump;
nsCOMPtr<nsIInputStream> mSynthesizedInput;
nsCOMPtr<nsIInterceptedBodyCallback> mSynthesizedCallback;
int64_t mSynthesizedStreamLength;
bool mIsFromCache;
bool mCacheEntryAvailable;
---Type <return> to continue, or q <return> to quit---q
Quit

Can you verify or update the test case?

[The leading "::" problem also seems to have been fixed.]

[keiths at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

--- Comment #3 from Keith Seitz <keiths at redhat dot com> ---
(In reply to Tom Tromey from comment #2)

I'm not sure bug 22968 is relevant here because "net" is a namespace.

I apologize about that comment. It was superfluous to the problem at hand -- an
unintended consequence of my prosaic writing style.

(gdb) ptype ::mozilla::net::HttpChannelChild
A syntax error in expression, near `mozilla::net::HttpChannelChild'.
One difference might be how we are building libxul.so.
Mine is huge (1.9G) so I'd rather not upload it though.

Out of curiosity, is the language set properly?

Testing here:
$ ./gdb -nx -q $firefox_obj/dist/bin/libxul.so
(gdb) show lang
The current source language is "auto; currently c".
(gdb) ptype mozilla::net::HttpChannelChild
No type "net" within class or namespace "mozilla".
(gdb) set lang c++
(gdb) ptype mozilla::net::HttpChannelChild
type = class mozilla::net::HttpChannelChild : public
mozilla::net::PHttpChannelChild, public mozilla::net::HttpBaseChannel
, public mozilla::net::HttpAsyncAborter<mozilla::net::HttpChannelChild>
, public nsICacheInfoChannel, public nsIProxiedChannel
, public nsIApplicationCacheChannel
, public nsIAsyncVerifyRedirectCallback
, public nsIAssociatedContentSecurity, public nsIChildChannel
, public nsIHttpChannelChild, public nsIDivertableChannel
, public nsIThreadRetargetableRequest, public
mozilla::net::NeckoTargetHolder {
private:
nsCOMPtr<nsISupports> mCacheKey;
nsCOMPtr<nsIChildChannel> mRedirectChannelChild;
RefPtr<mozilla::net::InterceptStreamListener> mInterceptListener;
nsCOMPtr<nsIStreamListener> mInterceptedRedirectListener;
nsCOMPtr<nsISupports> mInterceptedRedirectContext;
mozilla::net::RequestHeaderTuples mClientSetRequestHeaders;
RefPtr<nsInputStreamPump> mSynthesizedResponsePump;
nsCOMPtr<nsIInputStream> mSynthesizedInput;
nsCOMPtr<nsIInterceptedBodyCallback> mSynthesizedCallback;
int64_t mSynthesizedStreamLength;
bool mIsFromCache;
bool mCacheEntryAvailable;
---Type <return> to continue, or q <return> to quit---q
Quit

I think this is a result of the recent completer overhaul, which now uses the
language when searching for symbols. We are going to need to add some sort of
heuristic to catch this common use case.

[keiths at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

--- Comment #4 from Keith Seitz <keiths at redhat dot com> ---
(In reply to Keith Seitz from comment #3)

Post by keiths at redhat dot com
I think this is a result of the recent completer overhaul, which now uses
the language when searching for symbols.

Actually it has nothing to do with this. This problem has existed since at
least 7.2 (the earliest version of GDB I tried to build). I am testing a
possible solution for this, though.

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
It was indeed the missing "set lang c++".
Embarrassing! Thank you for pointing that out though.

[keiths at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

--- Comment #6 from Keith Seitz <keiths at redhat dot com> ---
(In reply to Tom Tromey from comment #5)

Post by tromey at sourceware dot org
It was indeed the missing "set lang c++".

Should we make an attempt to "fix" this or otherwise be a little more
user-friendly?

The problem here is that the parser really does not know the user's input
language. It currently assumes current_language. This is used in c_yylex to
determine the "context" of the processing, e.g., if it's not language_cplus, we
bail out early without any further consideration, even if the symbol we found
was a C++ symbol.

I have a patch to tweak this behavior, but I'm not sure how it would be
received upstream.

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=19274

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Keith Seitz from comment #6)

Post by keiths at redhat dot com
(In reply to Tom Tromey from comment #5)

Post by tromey at sourceware dot org
It was indeed the missing "set lang c++".

Should we make an attempt to "fix" this or otherwise be a little more
user-friendly?

I am not sure, but I tend to think we shouldn't bother.

I believe when I originally reported this bug, I was doing real debugging,
and so lang was c++. So, it was once a bug, since fixed.

Subsequent tests were done with "gdb libxul.so" - but this is a funny
sort of thing to do. There isn't a "main" in there (AFAIK) and so there
doesn't seem to be a principled reason to prefer one language over another,
because there's no particular symbol that makes sense as a default
source location.