This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bug! when a function is the parameter of another function.


"Peng-Sheng Chen" <pschen@puma.cs.nthu.edu.tw> writes:

|> Hello:
|> 
|>     If I write a C program which include a function is the parameter of another function,
|>     gcc will produce wrong assembly-code.
|>     
|>     ex : test.c
|>    		 void func1(void)
|> 		{
|> 		}
|> 
|> 		void func2(void *f)
|> 		{
|> 		}
|> 
|> 		int main(void)
|> 		{
|> 		  func2(&func1);
|> 		  return 1;
|> 		}
|> 
|>      Use option -fpic to producePIC code,  gcc produce follow :
|>         ......
|>         move.l func1@GOT.w(%a5),%d0
|>         ......

This is correct.  The GOT entry will contain the address of the function
at run time.  It does not matter whether it is a function or a data
object.

|>      func1 is a function pointer, not a data variable, it should produce follow :
|>         move.l func1@PLTPC,%d0

This is wrong.  @PLTPC only works with pc-relative addressing modes,
because it is defined to evaluate to the difference between the PC and the
PLT entry.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]