On Fri, 16 Mar 2001, gabriel rosenkoetter wrote:

> On Fri, Mar 16, 2001 at 03:13:53PM +0100, Ignatios Souvatzis wrote:
> 
> Assuming the below is a response just to that question, what about
> this?
> 
> -mlong-calls is one thing, but I don't *think* the gcc we're using
> even has a shortcall attribute. I wish I knew the piece of
> documentation from which to find that out, but, fwiw, changing my
> code to use __attribute ((shortcall)) where it had use longcall
> (blatantly wrong, but whatever), I get:
> 
> cc -D_LKM -D_KERNEL -I/sys  -c miscmod.c
> miscmod.c: In function `miscmod_handle':
> miscmod.c:95: warning: `shortcall' attribute directive ignored
> 
> ... which makes me think that shortcall doesn't actually exist. But
> I could be completely wrong, as always. :^>
> 
> (The original behemoth patch from the gcc mailing list even
> automatically generated shortcalls when referencing the something in
> the same code block under -mlong-call... but this seems to be part
> of the excessiveness that led to it's not being commited to gcc. Go
> figure.)

From looking at the resulting thread, it looks like the sticky point was
the roitine which tried to figure out if a short or long call was
appropriate. Actually, it was the routine
mark_fn_as_defined_in_this_file() which caused the concern. From what I
can gather, the functionality it was trying to achieve seemed to already
be there, so why add a duplicate routine. ??

I'm not 100% that the functionality was really duplicated - I don't
understand the compiler enough to tell. :-)

gr: if I understand things right, the concern is that the extra flagging
of "in this file" isn't needed. It looks like ENCODE_SECTION_INFO()
already covers this test. I think that undefining
MARK_FN_DEFINED_IN_THIS_FILE would disable that functionality.

Looking at the comments for ENCODE_SECTION_INFO(), it does the same thing,
though for a different reason:

/* If we are referencing a function that is static or is known to be
   in this file, make the SYMBOL_REF special.  We can use this to indicate
   that we can branch to this function without emitting a no-op after the
   call.  */

#define ENCODE_SECTION_INFO(DECL)  \
  if (TREE_CODE (DECL) == FUNCTION_DECL                 \
      && (TREE_ASM_WRITTEN (DECL) || ! TREE_PUBLIC (DECL))) \ 
    SYMBOL_REF_FLAG (XEXP (DECL_RTL (DECL), 0)) = 1; 

All of the places where calls to mark_fn_defined_in_this_file() are made
are within if statements wrapped by either (!TREE_PUBLIC (decl)) or
(TREE_ASM_WRITTEN (fndecl)). I think the (TREE_ASM_WRITTEN (DECL) ||
! TREE_PUBLIC (DECL)) part of the ENCODE_SECTION_INFO() macro does the
same thing. :-)

So Gabriel, I gather you have a compiler with this patch applied to it.
Could you try making a new gcc with just the #define
MARK_FN_DEFINED_IN_THIS_FILE(DECL) commented out? There is a test program
at the end of the thread which should see if things are fine (when you
compile it). Or just try compiling libstdc++. If the asm is the same both
ways, then dropping MARK_FN_DEFINED_IN_THIS_FILE() is the thing to do. If
the ASM is different, then there might be a problem.

Take care,

Bill