Fine, make me actually look up what I did... It's covered in the GCC manual,
or at least it is in the EGCS-2.95.2 version thereof.

#define LONGCALL __attribute__ ((longcall))

void flash_ident_acc(void) LONGCALL;

The __attribute__ (()) is GNU's syntax for such implementation specific
attributes, longcall is the attribute in question.  Notice also that the
attribute has to come after the prototype args, not before it.  I don't know
if it's valid to prepend an extern or not, I seem to remember it being
rather fussy syntactically.

The linker won't get confused because you aren't creating a second object,
you're just saying, in this source file, when you generate code to _call_
this function, do it with the full 32 bit range because the target is (may
be) further away than a relative branch allows.

Good luck with it.

Gregory

> -----Original Message-----
> From: gabriel rosenkoetter [mailto:gr@eclipsed.net]
> Sent: Wednesday, August 02, 2000 4:48 PM
> To: Greg Kritsch
> Cc: 'ws@tools.de'; dgatwood@deepspace.mklinux.org;
> port-macppc@netbsd.org
> Subject: Re: Do LKMs work *at*all* on powerpc platforms?
> 
> 
> On Wed, Aug 02, 2000 at 03:15:40PM -0400, Greg Kritsch wrote:
> > #ifdef COMPILING_AN_LKM
> > #ifdef powerpc
> > #ifdef __GNUC__
> > #define LKMATTR   __attribute__ ((far))
> > #else
> > #error don't know how to force far calls
> > #endif /* __GNUC__ */
> > #endif /* powerpc */
> > #else
> > #define LKMATTR   
> > #endif
> > 
> > int LKMATTR memcpy __P(...);
> 
> The linker won't bitch about conflicting definitions of memcopy in
> this kind of whackiness?
> 
> Erm. Maybe I'll find out for myself.
> 
> Can you suggest exactly what should go in those spaces? Why is (or
> just is) the __attribute__ necessary?
> 
> Is the modifier for the prototype "far" or "long"?
> 
>        ~ g r @ eclipsed.net
>