OC?

OC?

[Andrew Cagney]

Marko,

What changes to the core of gdb are still needed for your target?

Andrew

Re: OC?

[Marko Mlinar]

On Tuesday 10 December 2002 23:01, Andrew Cagney wrote:
> Marko,
>
> What changes to the core of gdb are still needed for your target?
>
> Andrew

Hi Andrew!

thanks for coming back to me.

As far as I can recall:

#define HAVE_NONSTEPPABLE_WATCHPOINT
Needs to be discussed whether to add it to architecture or target vector?

We have also problems with registers. You were saying something that we should 
move all the registers (we have 8k+ registers with generated names) into the 
temporary storage (I hope all these won't get cached in the host...).

I hope I have not missed anything; we will see what is comming anyway after we 
try to build the files.

best regards,
Marko

Re: OC?

[Andrew Cagney]

> On Tuesday 10 December 2002 23:01, Andrew Cagney wrote:
> 
>> Marko,
>>
>> What changes to the core of gdb are still needed for your target?
>>
>> Andrew
> 
> 
> Hi Andrew!
> 
> thanks for coming back to me.
> 
> As far as I can recall:
> 
> #define HAVE_NONSTEPPABLE_WATCHPOINT
> Needs to be discussed whether to add it to architecture or target vector?

Turns out this has been done.

> We have also problems with registers. You were saying something that we should 
> move all the registers (we have 8k+ registers with generated names) into the 
> temporary storage (I hope all these won't get cached in the host...).

Yes.  A gui for instance will likely want access to all names at once.

> I hope I have not missed anything; we will see what is comming anyway after we 
> try to build the files.

Andrew

Re: OC?

[Marko Mlinar]

Hi Andrew!

> Turns out this has been done.
>
> > We have also problems with registers. You were saying something that we
> > should move all the registers (we have 8k+ registers with generated
> > names) into the temporary storage (I hope all these won't get cached in
> > the host...).
>
> Yes.  A gui for instance will likely want access to all names at once.
I tried to fix this issue, but there were not enough documentation nor such 
targets for me to dig through. Is it possible that you (or somebody else) 
change this please?

We already have register name generators and all such stuff, it would only 
need connections to gdb routines.

thanks,
Marko

Re: OC?

[Andrew Cagney]

> Hi Andrew!
> 
> 
>> Turns out this has been done.
>>
> 
>> > We have also problems with registers. You were saying something that we
>> > should move all the registers (we have 8k+ registers with generated
>> > names) into the temporary storage (I hope all these won't get cached in
>> > the host...).

8k * 8 bytes ~= 64k.

Either that all lives in the text segment, or it is only allocated when 
all the names are asked for.

>> Yes.  A gui for instance will likely want access to all names at once.
> 
> I tried to fix this issue, but there were not enough documentation nor such 
> targets for me to dig through. Is it possible that you (or somebody else) 
> change this please?

I'm not sure what the problem is.  Just wrap the current code in 
something that maintains a table of previously returned names.

Andrew

Re: OC?

[Marko Mlinar]

On Tuesday 28 January 2003 20:45, Andrew Cagney wrote:
> > Hi Andrew!
> >
> >> Turns out this has been done.
> >>
> >> > We have also problems with registers. You were saying something that
> >> > we should move all the registers (we have 8k+ registers with generated
> >> > names) into the temporary storage (I hope all these won't get cached
> >> > in the host...).
>
> 8k * 8 bytes ~= 64k.
>
> Either that all lives in the text segment, or it is only allocated when
> all the names are asked for.

Andrew,

I was referring more to register transfer. Most of the registers should not be 
chached at all -- the value read from these special purpose registers (SPRs) 
can differ in time/access. Some registers may also have clear-after-read, 
FIFO implemented or any other obscure functionality.

It would be nice if all names would be generated, instead of storing their 
names, however I suppose nobody with our target will complain about high 
memory usage.

Another problem is with printing it out and displaying. Unfortunatelly I don't 
know how exaclty the remote debuggers work (we mostly use DDD), but if they 
try to read all registers when e.g. they reach breakpoint -- it will break 
the target (because e.g. clear-after-read). And besides it may take a while 
to load them all in.

> >> Yes.  A gui for instance will likely want access to all names at once.
> >
> > I tried to fix this issue, but there were not enough documentation nor
> > such targets for me to dig through. Is it possible that you (or somebody
> > else) change this please?
>
> I'm not sure what the problem is.  Just wrap the current code in
> something that maintains a table of previously returned names.

I don't know a lot of internals, which are common knowledge for most here, and 
I didn't know if my solutions would solve all above issues.

thanks,
Marko

Re: OC?

[Andrew Cagney]

> On Tuesday 28 January 2003 20:45, Andrew Cagney wrote:
> 
>> > Hi Andrew!
>> >
> 
>> >> Turns out this has been done.
>> >>
> 
>> >> > We have also problems with registers. You were saying something that
>> >> > we should move all the registers (we have 8k+ registers with generated
>> >> > names) into the temporary storage (I hope all these won't get cached
>> >> > in the host...).
> 
>>
>> 8k * 8 bytes ~= 64k.
>>
>> Either that all lives in the text segment, or it is only allocated when
>> all the names are asked for.
> 
> 
> Andrew,
> 
> I was referring more to register transfer. Most of the registers should not be 
> chached at all -- the value read from these special purpose registers (SPRs) 
> can differ in time/access. Some registers may also have clear-after-read, 
> FIFO implemented or any other obscure functionality.

Ah, sorry.

The first thing that would need to be changed is the regcache.  Have a 
way of marking a register as un-cachable.

Andrew