headers
Daniel Jacobowitz | 1 Dec 2008 01:10

Re: xmalloc for gdbserver?

On Sun, Nov 30, 2008 at 01:58:40PM -0800, Doug Evans wrote:
> Do we want to create versions of xmalloc, et.al. for gdbserver?
> I'll submit a patch for whichever way we choose, I just need to
> know which way to go.

Seems fine to me.  I just haven't done it because, to the best of my
knowledge, none of them have ever failed :-)

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Michael Snyder | 1 Dec 2008 23:24
Favicon

Re: Cannot get thread event message: debugger service failed

D. Hugh Redelmeier wrote:
> I'm trying to debug Firefox on Linux.  I'm using GDB.  Execution of
> Firefox is frequently interrupted with this message:
>   [New Thread 0x44125950 (LWP 30469)]
>   Cannot get thread event message: debugger service failed
> At this point, I enter a "continue" GDB command and execution
> proceeds.
> 
> Sometimes the screen locks up until the "continue".  So I need to run
> GDB somewhere other than the X desktop.
> 
> What is the best way to avoid this problem and get on with debugging 
> Firefox?  (I admit: a quixotic quest.)
> 
> Google finds this for me:
>   http://sourceware.org/ml/gdb/2006-10/msg00259.html
> but I don't see a resolution.
> 
> Some details:
> 
> - I get this message on 64-bit Fedora 9 (on a dual-core machine) and on 
>   64-bit Ubuntu 8.04 (on a quad core machine)
> 
> - GDB on Fedora 9: gdb-6.8-23.fc9.x86_64
> 
> - GDB on Ubuntu 8.04: 6.8-1ubuntu3
> 
> 
> - I run Firefox this way: Firefox --sync
>   or: Firefox --sync -no-remote
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Kratochvil | 2 Dec 2008 15:22
Picon
Favicon

Re: checking build IDs in core files

Hi,

currently not in the FSF GDB repository.

There is a patch for it for gdb-6.8 (being ported to HEAD now)
  http://cvs.fedora.redhat.com/viewvc/rpms/gdb/devel/gdb-6.6-buildid-locate.patch?view=co

but it has currently merged two unrelated functionalities:
(a) The expected locating of appropriate binaries from a bare core file.
(b) Reporting missing debuginfo rpms from missing .debug files.

The patch will get submitted for a review for FSF GDB after some cleanups.

Regards,
Jan

On Tue, 25 Nov 2008 04:31:53 +0100, Nathan Miller wrote:
> Hello-
> 
> Does GDB do anything with the build IDs contained within a core file?
> 
> It looks like they're completely ignored in the core file, and only extracted from a binary file in order to
find a separate debug file.
> 
> Am I missing something here?
> 
> Thanks,
> Nate
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Tromey | 2 Dec 2008 18:37
Picon
Favicon

Re: std::string and MI

>>>>> "André" == André Pönitz <apoenitz <at> trolltech.com> writes:

[...]
André> In both cases the 'std::' namespace is missing from the type.

André> As the "namespace foo" example above shows, this can't be the general
André> problem with namespaces, as "foo::string" is reported as I expected.

André> Does anybody know how to tweak gdb's settings so that it produces the
André> std:: namespace, too?

I didn't look at this example, but in other cases where "whatis"
printed something odd, I have tracked the problem down to weird debug
info.  You might take a look at that.  IOW, it may not be gdb's
decision.  There's a GCC PR or two in this area.

Tom
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 3 Dec 2008 18:27

Re: std::string and MI

On Thu, Nov 27, 2008 at 01:38:56PM +0100, André Pönitz wrote:
> I get after issuing a  "-stack-list-locals 2" the response
> 
>    ^done,locals=[{name="s",type="string"},{name="f",type="foo::string"},
>     {name="t",type="string"}]
> 
> Similarily,  "-var-create s * s" followed by "-var-info-type s" produces  
> 
>    ^done,type="string"
> 
> In both cases the 'std::' namespace is missing from the type.

I'll second Tom - I think I opened a GCC bug report about this.

> Incidentally: Would it be possible to extend the MI commands that output
> types to also produce the mangled types? (This could be restricted to the
> cases where these actually differs from the unmangled ones, but I really 
> don't mind duplicated output)

There's not really any such thing in the debug info.  Some GCC debug
info includes mangled names for functions, but it's not always there
and it is never present for types.  We'd have to reconstruct it from
linkage names and map to parameters; it would be very hit-or-miss.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Mihai Stanescu | 3 Dec 2008 20:18
Picon
Gravatar

High cpu usage when stepping in a function

Hello all

I have a very annoying problem with gdb 6.8 (also happened in previous
versions). My system is gentoo (x86).

So, i have a dynamically linked very large executable (300mb - libs +
main program). My problem is that if i stop in a breakpoint and try to
STEP into a function sometimes this thing takes ages, my cpu goes to
100% utilization and keeps this way. Eventually gdb enters that
function. My guess is gdb is searching for something. This thing never
happens when statically linked but the static, linking takes ages.

Thx
Mihai
Permalink | Reply | 0 comments |
headers
Srinath Avadhanula | 3 Dec 2008 21:56
Picon

Crash using '-stack-list-frames'

Hi,

Gdb is crashing on me when I try to use the command 'interpreter mi
"-stack-list-frames 0 182"'. I debugged gdb using gdb and found that
it gets into an infinite recursion with the first few frames being as
below.

Unfortunately, I am unable to come up with a simple test program which
reproduces the problem. I would be glad to help further if given any
pointers.

The version of gdb I am using is:

GNU gdb (GDB) 6.8.50.20081117-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Regards,
Srinath

PS: The stack frame where it crashes:

#0  0x000000000063d744 in d_print_comp (dpi=0x7fffffffd430, dc=0x78488a0)
    at .././libiberty/cp-demangle.c:3402
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Evans | 4 Dec 2008 21:18
Picon
Favicon

call_function_by_hand doesn't restore target async?

Hi.

Should there be a cleanup to restore target_async_mask?

call_function_by_hand has this:

  {
    struct cleanup *old_cleanups = make_cleanup (null_cleanup, 0);
    struct cleanup *old_cleanups2;
    int saved_async = 0;
    struct thread_info *tp = inferior_thread ();

    /* Save this thread's ptid, we need it later but the thread
       may have exited.  */
    this_thread_ptid = tp->ptid;

    /* If all error()s out of proceed ended up calling normal_stop
       (and perhaps they should; it already does in the special case
       of error out of resume()), then we wouldn't need this.  */
    make_cleanup (breakpoint_auto_delete_contents, NULL);

    disable_watchpoints_before_interactive_call_start ();
    tp->proceed_to_finish = 1; /* We want stop_registers, please... */

    if (target_can_async_p ())
      saved_async = target_async_mask (0);

    old_cleanups2 = make_cleanup_restore_integer (&suppress_resume_observer);
    suppress_resume_observer = 1;
    make_cleanup_restore_integer (&suppress_stop_observer);
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Jacobowitz | 4 Dec 2008 21:42

Re: Crash using '-stack-list-frames'

On Wed, Dec 03, 2008 at 03:56:11PM -0500, Srinath Avadhanula wrote:
> Hi,
> 
> Gdb is crashing on me when I try to use the command 'interpreter mi
> "-stack-list-frames 0 182"'. I debugged gdb using gdb and found that
> it gets into an infinite recursion with the first few frames being as
> below.
> 
> Unfortunately, I am unable to come up with a simple test program which
> reproduces the problem. I would be glad to help further if given any
> pointers.

This is the C++ name demangler.  Set a breakpoint at it and find what
input is taking it to this recursion?

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Pedro Alves | 4 Dec 2008 22:23

Re: call_function_by_hand doesn't restore target async?

On Thursday 04 December 2008 20:18:37, Doug Evans wrote:

> Should there be a cleanup to restore target_async_mask?
> 

>     if (target_can_async_p ())
>       saved_async = target_async_mask (0);
> 
>     old_cleanups2 = make_cleanup_restore_integer (&suppress_resume_observer);
>     suppress_resume_observer = 1;
>     make_cleanup_restore_integer (&suppress_stop_observer);
>     suppress_stop_observer = 1;
>     proceed (real_pc, TARGET_SIGNAL_0, 0);
>     do_cleanups (old_cleanups2);
> 
>     if (saved_async)
>       target_async_mask (saved_async);

> 
> target.h has this:
> 
> /* This is to be used ONLY within call_function_by_hand(). It provides
>    a workaround, to have inferior function calls done in sychronous
>    mode, even though the target is asynchronous. After
>    target_async_mask(0) is called, calls to target_can_async_p() will
>    return FALSE , so that target_resume() will not try to start the
>    target asynchronously. After the inferior stops, we IMMEDIATELY
>    restore the previous nature of the target, by calling
>    target_async_mask(1). After that, target_can_async_p() will return
>    TRUE. ANY OTHER USE OF THIS FEATURE IS DEPRECATED.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane