RS6000_MCOUNT and -fpic

[gp@qnx.com]

Thanks, Jim.  I appreciate the feedback, and I'll investigate as per your 
suggestions.  I'll also put together a small patch for the '@plt' and submit 
it to the patches list.

Cheers.
GP

Jim Wilson <wilson@specifixinc.com> said:

> gp@qnx.com wrote:
> >   if (flag_pic && DEFAULT_ABI == ABI_V4)
> >     fprintf("\tbl %s@plt",RS6000_MCOUNT);
> >   else
> >     fprintf("\tbl %s",RS6000_MCOUNT);
> 
> It looks like the same construct used in several places in the rs6000.md 
> file, so it seems to be right.
> 
> > - Why would I end up with a self-referencing "bl" instruction without the
> > "@plt"?  Any idea?  I think I've seen it before, so even though it looks 
> > like a bug, it might be a feature (I guess...)  :-)
> 
> probably a relocation got ignored or mishandled.
> 
> If you compile to a .o file without pic, and disassemble it, pc-relative 
> calls will look like calls to themselves.  However, if you look at the 
> relocation table, you will see a reloc that modifies the call target to 
> contain the address of the target function.  So after linking it will 
> point to the right place, but before linking it just has a placeholder 0 
> offset, which for most targets means a call to itself.
> 
> With pic, the relocation handling is a bit different.  It may be that 
> you still have an unhandled reloc after linking, and the call still has 
> the placeholder 0.  If the loader silently ignores the (presumably bad) 
> reloc, then the program will silently fail.  Or if the loader mishandles 
> the reloc things fail.  Alternatively, it could be that the linker 
> mishandled the reloc, or silently ignored it.  You would have to look at 
> the resulting executable including its relocs, and the linker/load 
> behaviour, and what the ABI says about these relocs.  There are lots of 
> different things that might have happened here.
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
> 



--