gdbint.info; Was: Obsolete m32r?

[Andrew Cagney <ac131313 at cygnus dot com>]

> 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!