problems in libgcc2.c:__bb_exit_function & __bb_init_func

[Dan Nicolaescu <dann at adaptive dot ics dot uci dot edu>]

Hi!

(the compiler I am talking about here is from the egcs-19992401 snapshot)

It looks like there are problems for basic block profiling. 

I was trying to determing why when I use gcc -ax -g the bb.out file
does not contain line numbers. 

I got to the following sequence in libgcc2.c:__bb_exit_function


      /* We check the length field explicitly in order to allow compatibility
	 with older GCC's which did not provide it.  */

      for (ptr = bb_head; ptr != (struct bb *) 0; ptr = ptr->next)
	{
	  int i;
	  int func_p	= (ptr->nwords >= sizeof (struct bb)
			   && ptr->nwords <= 1000
			   && ptr->functions);
	  int line_p	= (func_p && ptr->line_nums);
	  int file_p	= (func_p && ptr->filenames);


On an i386-linux-gnu 
ptr->nwords is 40
and
sizeof (struct bb) is 44

so func_p is 0 that determines that the line numbers and file name are
not printed in the bb.out file.

I inveverted the ptr->nwords >= sizeof (struct bb) comparison and I
got the line numbers and file names in bb.out. 

Is this correct? I have no idea, ptr->nwords is only used in that
place in libgcc2.c, so I don't know ptr->why it is 40.

It looks like a "struct bb*" is passed to __bb_init_trace_func or 
__bb_init_func from the FUNCTION_BLOCK_PROFILER or BLOCK_PROFILER
macros. 

This is weird because "struct bb" is defined in libgcc2.c and the
*BLOCK_PROFILER  macros are defined in the architecture specific file,
but yet they manage somehow to produce a pointer compatible with
"struct bb".  (black magic :-)

Actually I suspect that there is some problems with this pointer
passing. 

As I said on i386-linux-gnu the line numbers are not printed, on 
sparc-sun-solaris2.5.1 there is another problem:
an executable compiled with gcc -ax -g does not even try to open the
"bb.in" file. I didn't get to debug this one, but running 
truss (Solaris-speak for strace) on an executable compiled with -ax -g
shows that it opens "bb.out" but does not try to open "bb.in" as 
libgcc2c:__bb_init_prg says it should...


I am willing to spend some time to get these things cleared out, and
get the basic block profiling working, but I need some
guidance. Anybody willing to look at this tell me which way to go?
(I also reported a bug to egcs-bugs yesterday about calls 
generated in object filles compiled with -g -ax on
sparc-sun-solaris2.5.1 to 
___bb_init_trace_func
instead of
__bb_init_trace_func when all the other __bb function calls only have
2 underscores...)

Thanks for a great compiler!

--dan