* Re: HOWTO move a target from old style multiarched to new style multiarched?
2003-06-11 12:02 HOWTO move a target from old style multiarched to new style multiarched? Corinna Vinschen
2003-06-11 18:44 ` Eli Zaretskii
@ 2003-06-12 17:00 ` Andrew Cagney
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2003-06-12 17:00 UTC (permalink / raw)
To: gdb, Corinna Vinschen
> Hi,
>
> there were a lot of changes in the last couple of months to convert gdb
> to a new way of doing things. That's probably good but I don't know how
> many people actually understand the whole process. I must admit, I don't.
This was my most recent guess:
http://sources.redhat.com/ml/gdb/2003-05/msg00399.html
Briefly, slow eliminate each set_gdbarch_deprecated* call, the rest will
follow.
> I'm under the impression the documentation is missing an important part.
> There's some sort of description spread over the source code now but it
> doesn't give a coherent picture and I also didn't find that in the docs.
There isn't a single picture as there isn't a single change. Instead
there are three largely independant changes:
- frames (the obvious one)
- inferior function calls
- global buffer -> regcache or frame
> Wouldn't it be possible to write a HOWTO for the poor developer soul,
> who's left behind with a target with now using 80% deprecated functions?
> IMHO, that HOWTO written by somebody who knows what's going on could
> tells us
To speak personally, I think it is dangerous for someone to post a HOWTO
on something they haven't done :-/ I, for instance, have only done the
d10v and there my only recommendation is to not follow my lead. I have
posted several theoretical guidelines but there, it's strictly
conjecture, and the suggestions haven't received any feedback.
Contrast this to multi-arch where the process was documented after I'd
done several [partial] multi-arch conversions -> I knew it worked.
Anyway, here is an expansion of the last post:
for method in set_gdbarch_deprecated* do
look in gdbarch.sh to see if there is a direct replacement
ex: UNWIND_SP is a direct replacement for TARGET_READ_SP
look in the d10v for an example
(this should be pretty obvious, replace A with B)
for method in set_gdbarch_deprecated* do
look in gdbarch.sh to see if it is a dummy-frame related function
ex: The dummy call frame SP should be set by push_dummy_call
ex: This is simply not needed. ...
move, implement, or delete the relevant code
cut a USER_CPU_frame branch
- implement a traditional unwinder so that the basics are working
- implement additional unwinders for sigtramps and the like
- replace the lot
But remember, I don't know if this process works, I've not tried it.
As for doco, the bit I acknowledge is missing is an architectural
overview of the frame code. The regcache does have posted doco:
http://sources.redhat.com/ml/gdb/2002-07/msg00202.html
Andrew
> The datastructure `struct bits' is replaced by `struct pieces'.
> This requires to use a new set of functions...
>
> Create functions foo(), bar() and baz(), doing...
>
> If you use function new_and_shiny() you must also replace
> old_and_dirty(), otherwise...
>
> The functions old() and cruft() are replaced by glitter() which
> returns yadda...
>
> Function ugly() is not used anymore and can be removed without
> substitution...
>
> and so on. That would be very helpful and probably speed up the
> conversion of targets to "new style" enormously.
>
> Or did I just miss the documentation on this?
>
> Corinna
>
> -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com
^ permalink raw reply [flat|nested] 3+ messages in thread