From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Mark Klein Cc: gcc@gcc.gnu.org Subject: Re: MPE Port Date: Mon, 25 Oct 1999 22:41:00 -0000 Message-id: <14653.940915805@upchuck> References: <4.1.19990907082210.00c21980@garfield.dis.com> X-SW-Source: 1999-10/msg00629.html 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Mark Klein Cc: gcc@gcc.gnu.org Subject: Re: MPE Port Date: Sun, 31 Oct 1999 23:35:00 -0000 Message-ID: <14653.940915805@upchuck> References: <4.1.19990907082210.00c21980@garfield.dis.com> X-SW-Source: 1999-10n/msg00627.html Message-ID: <19991031233500.VfG6w1mOUlGarRARCOmTTu2MtiRCANWgaTEWV_lgwkI@z> 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