From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@ges.redhat.com>
Cc: Quality Quorum <qqi@theworld.com>, gdb@sources.redhat.com
Subject: Re: RFC: Two small remote protocol extensions
Date: Wed, 28 Aug 2002 09:49:00 -0000 [thread overview]
Message-ID: <20020828165012.GA2384@nevyn.them.org> (raw)
In-Reply-To: <3D6CFE05.5080502@ges.redhat.com>
On Wed, Aug 28, 2002 at 12:44:53PM -0400, Andrew Cagney wrote:
> >It does not mean that everybody else should suffer, it is time to fix
> >>>> > this youthful indiscretion.
> >
> >>>
> >
> >>>>
> >>>> Humor me. So who is suffering?
> >
> >>>
> >>>
> >>> All things embedded and I suppose it is a much bigger market/user group
> >>> than ***ix one.
> >
> >>
> >>Why are ``all things embedded'' suffering?
> >>
> >>I know of two cases:
> >>
> >>a) The threads have a 100% shared address space. Binding memory
> >>accesses to a thread will make zero difference.
> >>
> >>b) The threads do not have a 100% shared address space. Binding memory
> >>accesses to a thread will at least make it better reflect GDB's view of
> >>a threads address space.
> >>
> >
> >
> >Forcing model (b) on underlying environment (a) will force unnecessary
> >invalidations of memory cache and will pretty negatively affect
> >performance of a debugging session.
>
> I don't believe that it is even possible to measure a cache effect when
> profiling GDB's single step performance(1) --- other, far bigger, host
> or host<->target things things will drown any cache effects.
>
> Anyway, in case (a), since GDB won't be able to detect which thread was
> used to do the read --- the target is still free to use a thread, any
> thread.
I assume he meant GDB's dcache. Which is a real lifesaver, except when
it actually slows things down.
> >I would perefer to treat (b) as a separate process (and run separate gdb
> >instance to debug it a-la vxWorks and normal multi process debugging),
> >however, it will be fine to make this thing a configurable run time
> >parameter. At the sime time of forcing (a) to emulate (b) does not seem
> >appropriate.
>
> A target is always free to implement (b) using separate GDBs.
This is certainly true. HP even has fragmented code to do it natively.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-08-28 16:49 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-01 19:25 Daniel Jacobowitz
2002-05-02 8:38 ` Andrew Cagney
2002-05-02 8:52 ` Daniel Jacobowitz
2002-05-02 9:39 ` Andrew Cagney
2002-05-02 12:14 ` Daniel Jacobowitz
2002-05-02 12:22 ` Kevin Buettner
2002-05-02 12:34 ` Daniel Jacobowitz
2002-05-02 13:13 ` Andrew Cagney
2002-05-02 14:09 ` Daniel Jacobowitz
2002-05-03 11:24 ` Andrew Cagney
2002-05-03 14:28 ` Daniel Jacobowitz
2002-05-03 15:18 ` Andrew Cagney
2002-05-03 15:22 ` Daniel Jacobowitz
2002-05-04 19:59 ` Andrew Cagney
2002-05-02 13:13 ` Quality Quorum
2002-05-02 14:13 ` Daniel Jacobowitz
2002-05-03 13:07 ` Andrew Cagney
2002-08-16 7:30 ` Daniel Jacobowitz
2002-08-16 7:42 ` Andrew Cagney
2002-08-16 7:52 ` Daniel Jacobowitz
2002-08-16 8:21 ` Andrew Cagney
2002-08-22 19:23 ` Andrew Cagney
2002-08-22 19:36 ` Daniel Jacobowitz
2002-08-23 7:24 ` Quality Quorum
2002-08-23 7:26 ` Daniel Jacobowitz
2002-08-23 7:49 ` Quality Quorum
2002-08-23 8:57 ` Andrew Cagney
2002-08-23 11:16 ` Quality Quorum
2002-08-23 12:39 ` Andrew Cagney
2002-08-23 13:10 ` Quality Quorum
2002-08-27 20:23 ` Andrew Cagney
2002-08-28 8:31 ` Quality Quorum
2002-08-28 9:44 ` Andrew Cagney
2002-08-28 9:49 ` Daniel Jacobowitz [this message]
2002-08-22 21:08 ` Andrew Cagney
2002-08-23 5:44 ` Daniel Jacobowitz
2002-08-23 12:10 ` Andrew Cagney
2002-08-23 12:53 ` Andrew Cagney
2002-08-23 13:15 ` Daniel Jacobowitz
2002-08-27 21:07 ` Andrew Cagney
2002-08-28 6:33 ` Daniel Jacobowitz
2002-09-25 8:51 ` Daniel Jacobowitz
2002-09-25 11:17 ` Andrew Cagney
2002-09-26 18:39 ` Andrew Cagney
2002-09-26 18:48 ` Andrew Cagney
2003-06-29 7:51 ` Daniel Jacobowitz
2003-09-03 23:41 ` Andrew Cagney
2003-09-17 15:51 ` Daniel Jacobowitz
2003-09-17 16:19 ` Andrew Cagney
2003-09-17 16:23 ` Daniel Jacobowitz
2003-09-22 0:27 ` Andrew Cagney
2003-09-22 1:01 ` Daniel Jacobowitz
2003-09-22 3:02 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020828165012.GA2384@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@ges.redhat.com \
--cc=gdb@sources.redhat.com \
--cc=qqi@theworld.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox