gdb hogs cpu at startup

[maestro]

Hello!

I try to debug firefox in cdt using gdb 6.8.
When I launch a debug gdb hogs one cpu with 100% for about 90seconds
before the debug target starts executing. Once the target is running
almost every breakpoint results in a "Target request failed: Target is
not responding (timed out)." error message, nontheless I can step
through the code after that error.

In contrast: When I launch gdb from a terminal with the same parameters
as configured for the debug in cdt the 90seconds startup lag does not
occur (the target starts executing right away, as one would expect) and
the debugger seems much more responsive than in cdt.

So I'm interested in what causes this startup lag and what can I do to
make gdb in cdt at least comparably fast to gdb run from a terminal.

thanks for your suggestions
--m

p.s. system is pentium d dual core 2.6GHz with 2Gb ram. Debian GNU\Linux
4.0 (aka etch), Eclipse 3.4.0, cdt 5.0.0.200806171202

[Schaefer, Doug]

Yes, that's probably the shared library handling we have in the CDT.
Since gdb pre-6.8 didn't have pending breakpoint support at the MI
layer, we had to catch all shared library load events and retry setting
the breakpoints. And Firefox has a lot of shared libraries.

Now that 6.8 does have pending breakpoint support we could use, we
should use it. Does anyone have plans to do this?

Doug.

> -----Original Message-----
> From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
> [mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of maestro
> Sent: Tuesday, September 09, 2008 11:51 AM
> To: cdt-debug-dev-j9T/***@public.gmane.org
> Subject: [cdt-debug-dev] gdb hogs cpu at startup
>
> Hello!
>
> I try to debug firefox in cdt using gdb 6.8.
> When I launch a debug gdb hogs one cpu with 100% for about
> 90seconds before the debug target starts executing. Once the
> target is running almost every breakpoint results in a
> "Target request failed: Target is not responding (timed
> out)." error message, nontheless I can step through the code
> after that error.
>
> In contrast: When I launch gdb from a terminal with the same
> parameters as configured for the debug in cdt the 90seconds
> startup lag does not occur (the target starts executing right
> away, as one would expect) and the debugger seems much more
> responsive than in cdt.
>
> So I'm interested in what causes this startup lag and what
> can I do to make gdb in cdt at least comparably fast to gdb
> run from a terminal.
>
> thanks for your suggestions
> --m
>
> p.s. system is pentium d dual core 2.6GHz with 2Gb ram.
> Debian GNU\Linux 4.0 (aka etch), Eclipse 3.4.0, cdt 5.0.0.200806171202
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev-j9T/***@public.gmane.org
> https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>

[Pawel Piech]

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev-j9T/***@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

[maestro]

Am Dienstag, den 09.09.2008, 08:59 -0700 schrieb Schaefer, Doug:
> Yes, that's probably the shared library handling we have in the CDT.
> Since gdb pre-6.8 didn't have pending breakpoint support at the MI
> layer, we had to catch all shared library load events and retry setting
> the breakpoints. And Firefox has a lot of shared libraries.

Can I turn that shared library handling off somehow? A 90 second lag in
the debug cycle really is time-consuming.

cheers
--m

[L***@public.gmane.org]

Hi, there,

This seems like a basic issue that's not clearly defined.

In the CDT (and DSF) launch configuration preference panel "Arguments"
(internally CArgumentTab), there is the "Working directory" option. My
question is, what is that option supposed to mean, working directory of
the debugger (e.g. gdb), or that of the debugged program ?

For local debug, the difference usually does not matter much. But for
remote debug, the working directory of the debugged program should be a
dir on remote device/machine, while the working directory of the
debugger is on host PC.

>From the source code I can see that it's treated as working dir for
debugger.

But the UI is ambiguous. "arguments" are surely for debugged program, so
user would take it for granted that the "working directory" there is for
his program, though actually it's not.

Actually for a user, what he cares about is the working directory of his
program, not the debugger. But the UI (the "browse" buttons, and the
validator that checks if the directory exists on host PC) requires that
the working directory to be on host PC, which impose a problem for
remote debug.

So I think we should first decide on what the "working directory" should
be, and then decide on what to change about UI.

- Ling

[John Cortell]

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev-j9T/***@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

[L***@public.gmane.org]

John, I cann't agree more.

As to the UI, as we can hardly find a standard way of telling whether
it's remote debug or local, I think it will be up to each debug
implementation (product provider) to subclass or create its own
ArgumentTab and distinguish between remote and local in its own way. In
other words, the CArgumentTab from CDT & DSF should just be used as a
reference.

- Ling

________________________________

From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of ext John Cortell
Sent: Tuesday, September 09, 2008 1:31 PM
To: CDT Debug developers list; cdt-debug-dev-j9T/***@public.gmane.org
Subject: Re: [cdt-debug-dev] What's the "Working directory" in theLaunch
Config UI ?


Ling, for sure the working directory preference should represent the WD
of the program being debugged. Any treatment of it a anything else seems
like a bug to me and should be fixed. If we need a similar pref for gdb,
then that should go in the Debugger tab.

As for whether it makes sense for the LC to allow the user to navigate
to a local directory: the answer is yes, and no. Yes, if debugging
locally; no if debugging remotely. If there's a way to distinguish
within the LC UI, then the Workspace and File System... buttons should
be disabled. So, e.g., for a JTAG LC, those buttons should be disabled.
But I suspect that's the best we can do. In a standard LC, what would we
use as criteria for knowing it's a "remote" session. Even with gdbserver
as the selected debugger, you could conceivably be debugging an
executable running on the host.

John

At 01:18 PM 9/9/2008, Ling.5.Wang-***@public.gmane.org wrote:


Hi, there,

This seems like a basic issue that's not clearly defined.

In the CDT (and DSF) launch configuration preference panel
"Arguments"
(internally CArgumentTab), there is the "Working directory"
option. My
question is, what is that option supposed to mean, working
directory of
the debugger (e.g. gdb), or that of the debugged program ?

For local debug, the difference usually does not matter much.
But for
remote debug, the working directory of the debugged program
should be a
dir on remote device/machine, while the working directory of the
debugger is on host PC.

>From the source code I can see that it's treated as working dir
for
debugger.

But the UI is ambiguous. "arguments" are surely for debugged
program, so
user would take it for granted that the "working directory"
there is for
his program, though actually it's not.

Actually for a user, what he cares about is the working
directory of his
program, not the debugger. But the UI (the "browse" buttons, and
the
validator that checks if the directory exists on host PC)
requires that
the working directory to be on host PC, which impose a problem
for
remote debug.

So I think we should first decide on what the "working
directory" should
be, and then decide on what to change about UI.

- Ling


_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev-j9T/***@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

[Mikhail Khodjaiants]

If you uncheck "Load shared library symbols automatically" the debugger
won't stop on solib events. But you will need to load the symbols
manually in the modules view if you want to debug the library code.

-----Original Message-----
From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of maestro
Sent: Tuesday, September 09, 2008 5:31 PM
To: CDT Debug developers list
Subject: RE: [cdt-debug-dev] gdb hogs cpu at startup

Am Dienstag, den 09.09.2008, 08:59 -0700 schrieb Schaefer, Doug:
> Yes, that's probably the shared library handling we have in the CDT.
> Since gdb pre-6.8 didn't have pending breakpoint support at the MI
> layer, we had to catch all shared library load events and retry
> setting the breakpoints. And Firefox has a lot of shared libraries.

Can I turn that shared library handling off somehow? A 90 second lag in
the debug cycle really is time-consuming.

cheers
--m

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev-j9T/***@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.