[PATCH][PowerPC] Fix BlockAddress access on ppc64
Ulrich Weigand
Ulrich.Weigand at de.ibm.com
Thu Oct 30 17:29:59 PDT 2014
Anton Blanchard <anton at samba.org> wrote on 30.10.2014 21:41:25:
> > > The attached patch fixes this by loading such values from the TOC,
> > > as is done for any other global symbol.
> >
> > Thanks! I verified this fixed the issue for me.
>
> Sorry, I spoke too soon:
>
> kernel/built-in.o:(.toc+0x0): undefined reference to `.Ltmp371608'
>
> .Ltmp35: # Block address taken
> # BB#1: # %__here
> addis 3, 2, .LC7 at toc@ha
> li 4, 512
> ld 3, .LC7 at toc@l(3)
> bl __local_bh_enable_ip
>
> ...
>
> .LC7:
> .tc .Ltmp3543[TC],.Ltmp3543
Huh. It seems there is a pre-existing bug in code to write out the
TOC that cannot handle temporary labels:
for (MapVector<MCSymbol*, MCSymbol*>::iterator I = TOC.begin(),
E = TOC.end(); I != E; ++I) {
OutStreamer.EmitLabel(I->second);
MCSymbol *S = OutContext.GetOrCreateSymbol(I->first->getName());
if (isPPC64)
TS.emitTCEntry(*S);
The GetOrCreateSymbol call will note that ".Ltmp35" is not a symbol
(since it's a temporary label), so it will attempt to create a new
symbol with that name. This in turn will notice that the name
".Ltmp35" *is* already in use (as a temporary label), and thus
refuse to create a symbol of the same name. However, there is a
fallback path that assumes that since this is a temporary name,
it can be simply renamed, and does so ...
This is all particularly weird since I->first above already *is* a
MCSymbol, and I cannot see any reason why we'd need to create
*another* MCSymbol just to print it out. Simply using I->first
directly fixes the problem for me.
I've attached an updated version that implements that solution,
and enhances the test to actually verify the correct label name.
(See attached file: diff-llvm-ppc64-blockaddress)
Still OK for mainline?
Bye,
Ulrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-llvm-ppc64-blockaddress
Type: application/octet-stream
Size: 8892 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141031/0864a835/attachment.obj>
More information about the llvm-commits
mailing list