Luke A. Guest wrote: > Well, I'm reading as much as I can regarding this, but finding it hard > to work some things out.
That's a pretty complex and very precise machinery overall. > I've been reading through: > http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example > code in C++ and Ada, but it doesn't seem to match up in some places, > i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains > the function. There's a variety of registration functions and some targets don't resort to such calls at all, see unwind-dw2-fde-glibc.c. A quick glance suggests that your arm-linux port might be using the latter (from t-linux if I'm not mistaken, I'm not at all familiar with the port though). [...] > Yup, aware of this so far. [...] > Yup. > > raise-gcc.c hosts the Ada personality routine, where a number of changes > > will be needed I believe. > > Also, I think tracebak.c Sure, was just suggesting starters. You will have made good progress when you get to traceback issues :) It's useful to have a global idea of course. Another aspect is the possible need for special processing to get through signal handlers (the fallback_frame_state buisness on other targets). The capability to raise from signal handlers is often useful in Ada, and typically available with the base sjlj runtime. Not clear to me if this would require anything special not already there for arm-linux. > is where the ARM specific routine(s) will need to go, included from > another file tb-armlinux.c? > I think this will be required as (if I'm right), different ARM CPU's > have differing number of registers, and I think I read in the ARM > docs that float regs won't need to be saved if they're not used. I > could be wrong about this though. While I know there are arm-eabi specifics wrt unwinding, I'm really not familiar with the details so I'm not sure what exactly will be needed for traceback computations. Wouldn't tb-gcc.c "just work" (using _Unwind_Backtrace) ? If not, ISTM we'd more need something like a tb-armeabi variant. To be confirmed. > > There, please, I'd rather have the ARM specializations abstracted as > > much as possible, e.g. with new functions and alternate implementations, > > instead of provided as #ifdefs blocks spread within existing functions. > > Well, I think that's possible to a point, obviously some things will > have to go into ifdef's unfortunately (it's not Ada :D). Sure. All I'm saying is that I'd prefer #if ARM void foo () void bar () #else void foo () void bar () #endif void dosomething () { ... foo () ... bar () ... } or alternate C files to void dosomething () { ... #if ARM foo blob 1 #else foo blob 2 #endif ... #if ARM bar blob 1 #else bar blob 2 #endif } especially when that needs to be repeated in several places. > Hopefully, I can rely on some help from you AdaCore guys? Some, sure :) As I said we aren't familiar with the details of the ARM EH specifics and we're not running arm-linux in-house, so ... Now if you get something working, we can comment on the integration scheme for the Ada specific parts. > This is my first foray into GCC internals :/ Welcome :-D Out of curiosity, why did you choose that particular topic (ZCX for Ada on arm-linux) ? Does this just happen to seem of interest for learning purposes, or is there a more specific need ? Olivier
