Re: MPE Port

[Jeffrey A Law <law@cygnus.com>]

  In message <4.1.19990907082210.00c21980@garfield.dis.com>you write:
  > In message <4.1.19990906102304.00c72c80@garfield.dis.com>you write:
  > 
  > >> + #undef CPP_PREDEFINES
  > >> + #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
  > >> -Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"
  > 
  > >You should move the -D definitions into a CPP_SPEC string to avoid ANSI
  > >namespace pollution.
  > 
  > Hmmm. I just lifted the HP-UX code and change hp9000s800 to hp3000s900.
  > I'll change it as you suggest.
Thanks.  It would be nice to convert all the old stuff so that people don't
think what those older ports do is actually right ;-)  Time time time.


  > If you mean "does MPE allow the ability to execute code in the data stack?"
  > then, no. When I did the Java JIT for MPE for HP this was a major stumbling
  > area as MPE requires code to be in code pages, not data pages. The stack
  > area are all marked as data pages. I had to write some exotic kernel stuff
  > to create a code page that still got mapped into SR5 space to make the JIT
  > work. I suppose I can use the same techniques here. (I'll worry about that
  > when I get to the gdb port).
So, how does dynamic linking work on MPE?

I believe gdb has some capabilities to build inferior function call
stubs/trampolines in the text space, but it's fragile -- it depends on being
able to find enough space before/after the program to write it's little
stub/trampoline in the text segment.  If you don't have space, then you lose.
I also believe it is the case that few popular systems need this capability
so the code in gdb may have bitrotted.

It sounds like you're going to have to provide a stub of some kind for gdb's
use in inferior calls.  The structure is going to be radically different from
__gcc_plt_call, but the mechanism you use to get it bound into the executable
should probably mirror __gcc_plt_call.


  > 
  > >  > + #undef  ASM_DECLARE_FUNCTION_NAME
  > >  > + #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
  > [snip]
  > >If the only difference is that you need a PRIV_LEV=3 on a static function,
  >  I
  > >see no reason we can't promote that into som.h.  I believe that would
  > >eliminate the need for a separate ASM_DECLARE_FUNCTION_NAME, right?
  > 
  > I would prefer this route too. BTW - you mean pa.h, don't you? :-)
Me too.  Let's just tack on the PRIV_LEV=3 into som.h (yes, things moved :-)
I'll go ahead and do that now ;-)  So you can zap the ASM_DECLARE_FUNCTION_NAME
stuff from your changes.



jeff