Re: libgcc2.c troubles with volatile -- nope it's with PIC

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

Jeffrey A Law <law@hurl.cygnus.com> writes:

  >   In message <9902031653.aa05999@paris.ics.uci.edu>you write:
  >   > This one was a lot harder to track down:
  >   > 
  >   > It looks like asm volatile is not obeyed, code it's still moved
  >   > around. 
  >
  > Err, if you read the asm documentation it states explicitly that
  > even volatile asms can be mvoed around.

Yep, you're right. 

  >   > void
  >   > __bb_trace_func ()
  >   > {
  >   >   struct bb_edge *bucket;
  >   > 
  >   >   MACHINE_STATE_SAVE("1")
  >   > 
  >   > 
  >   > The macro is defined as: 
  >   > 
  >   > #define MACHINE_STATE_SAVE(ID)				\
  >   >   extern char flgtab[] __asm__(".LMSS"ID);		\
  >   >   unsigned long int ms_flags, ms_saveret;		\
  >   >   asm volatile("ta	0x20\n\t"			\
  >   > 	       "mov	%%g1, %0\n\t"			\
  >   > 	       "mov	%%g2, %1\n\t"			\
  >   > 	       : "=r" (ms_flags), "=r" (ms_saveret));
  >   > 
  >   > 
  >   > I look at the assembly code by extracting _bb.o from libgcc2.a 
  >   > ar x libgcc2.a _bb.o
  >   > dis _bb.o > _bb.s
  >   > 
  >   > In _bb.s 
  >   > __bb_trace_func()
  >   >         1228:  9d e3 bf 90         save         %sp, -112, %sp
  >   >         122c:  2f 00 00 00         sethi        %hi(0x0), %l7
  >   >         1230:  7f ff fc 0d         call         0x264
  >   >                                  ^^^^^^^^^^^^^^^^^
  >   >                                  this call was moved here, before the 
  >   > 				asm volatile
  >   >         1234:  ae 05 e0 00         add          %l7, 0, %l7
  >   >         1238:  91 d0 20 20         ta           0x20
  >   >         123c:  ac 10 00 01         mov          %g1, %l6
  >   >         1240:  b0 10 00 02         mov          %g2, %i0
  >   >         1244:  11 00 00 00         sethi        %hi(bb_src), %o0
  >   >         1248:  90 12 20 00         or           %o0, bb_src, %o0        ! b
  >
  > So, what is the target of that call?  Are you sure it's not
  > something the compiler inserted on purpose at the start of the
  > function?

Investigating further I am sure that it is something that the compiler
inserted on purpose at the beginning of the function: 

On sparc-solaris libgcc2.c is compiled with -fPIC, in the assembler
output the mentioned "call" appears as:

call .LLGETPC0

where .LLGETPC0 is:

.LLGETPC0:
        retl
        add %o7,%l7,%l7

So this is just the PIC code. 
The problem is that this code changes the state of the processor (for
sure the psr register (the flags register on sparc)), and we cannot
save/restore if reliably using the the
MACHINE_STATE_SAVE/MACHINE_STATE_RESTORE macros.


What is the solution for this? 

I would say don't use -fPIC when compiling libgcc2.c to get _bb.o? 
(This is what I did on my local tree, and it's fine for my needs)

The building process for  libgcc.a is quite complex, I don't know how
easy this would be to implement elegantly.

Another solution could be to introduce an new __atribute__(save_state)
for functions that are not supposed to change the state of the
processor, for functions marked like that we could take care of
emiting the PIC code after the code that saves the processor state. 

I hope there is something better that both of these... 

What do you think? 

--dan