This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: tracepoints implementation: bug in byte code generating.


> Josef Ezra wrote:
>
> > > > I thought about 'nAAAA,LLLL' and 'NAAAA,LLLL:XXXX' commands as an
> > > > alternative for 'm' and 'M' commands. In my case (EMC SYMMETRIX) it
> > could be
> > > > useful for indicating the target to get those addresses from a
different
> > > > memory space. Your idea of having a memory space argument is more
> > general
> > > > and flexible; I will be very happy to use it.
> > >
> > > May I ask what your separate memory spaces are?
> >
> >  We have multi CPU systems that have local and shared memory spaces that
> >  can have the same addresses from a pointer point of view.
>
> Do you mean that there are N data processors each with an area of common
> memory and a separate area of local memory (giving N local memory
> regions)?
>
> A better way to model that senario would be to view each data-processor
> as a thread.  Changing data-processor would result in a change in
> address space.
>
> Andrew
>

I can use this one for observing the data. Thank you.
I still need a generic way to declare a trace where local memory variable
points to another memory space; will be happy to hear more suggestions.

Thanks again -
Josef



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]