Obsolete m32r?

Obsolete m32r?

[Andrew Cagney]

Michael,

The m32r needs to be multi-arch.  I'm not sure what you want to do with 
it though.

You could, for instance, just let it be made obsolete.  Any thoughts?

Andrew

Re: Obsolete m32r?

[Michael Snyder]

Andrew Cagney wrote:
> 
> Michael,
> 
> The m32r needs to be multi-arch.  I'm not sure what you want to do with
> it though.
> 
> You could, for instance, just let it be made obsolete.  Any thoughts?

Mitsubishi still uses it (both the chip and the tools), 
so I don't think obsoleting it would be appropriate.

What brings this up?

Re: Obsolete m32r?

[Andrew Cagney]

> Andrew Cagney wrote:
> 
>> 
>> Michael,
>> 
>> The m32r needs to be multi-arch.  I'm not sure what you want to do with
>> it though.
>> 
>> You could, for instance, just let it be made obsolete.  Any thoughts?
> 
> 
> Mitsubishi still uses it (both the chip and the tools), 
> so I don't think obsoleting it would be appropriate.
> 
> What brings this up?


In GDB 5.2 we're ment to have everything multi-arched so this target 
needs to be done.   I don't actually think that goal will be achived but 
we should at least be working on it.

Andrew

Re: Obsolete m32r?

[LeakyStain]

It would help if the gdbint.info was updated first, to label the macros
obsolete or deprecated, and describe multi-arch more completely.

I started working on a port of gdb 5.0 to the ut69r in September 2001, 
and I read gdbint.info pretty thoroughly; there was only one mention of
multi-arch, and it was pretty obscure. So I implemented the macros, and 
now I discover I have to change them.

-- Stephe

Andrew Cagney wrote:

> In GDB 5.2 we're ment to have everything multi-arched so this target
> needs to be done.   I don't actually think that goal will be achived but
> we should at least be working on it.
> 
> Andrew

gdbint.info; Was: Obsolete m32r?

[Andrew Cagney]

> It would help if the gdbint.info was updated first, to label the macros
> obsolete or deprecated, and describe multi-arch more completely.


Obsolete macros are deleted (when someone notices they are not in use or 
removes all uses).  There is no pre-documented warning that this will 
happen however strong hints are found on 
http://sources.redhat.com/gdb/ari/ .

The intention (discussed last year) is to more clearly identify 
deprecated macro's and functions by adding the prefix deprecated_....().


> I started working on a port of gdb 5.0 to the ut69r in September 2001, 
> and I read gdbint.info pretty thoroughly; there was only one mention of
> multi-arch, and it was pretty obscure. So I implemented the macros, and 
> now I discover I have to change them.


Prior to the 5.1 release I tried to update the internals doco so that it 
better represented current reality (1, 2):

http://sources.redhat.com/gdb/onlinedocs/gdbint_9.html#SEC67

The introduction is correct.  The misleading part is where it uses the 
words macro vs function.  Looking at it I probably should have simply 
replaced all uses of the word macro with function (it is complicated 
because currently most architecture methods are still accessed via a 
macro by core-GDB :-/).  The section on files points out that tm-*.h 
files are not needed and should not be created.

Overall it could do with more work.  With 5.1 I was more worried about 
getting the coding standard section to better reflect reality.

If you're wondering about the big picture see:

http://sources.redhat.com/gdb/papers/multi-arch/whatis.html

http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/


If you're wondering what you need to change see:
http://sources.redhat.com/gdb/papers/multi-arch/howto.html


Andrew


(1) GDB currently isn't multi-arch.  At this stage multi-arch just 
refers to implementing a target using the architecture vector.

(1) Hmm, section 9.1 is completly out-of-date.  GDB and the compiler's register numberings are now completly independant!