[PATCH] Implement getNoopForMachoTarget for SPARC

[Brad Smith]

On 09/09/14 9:11 PM, Eric Christopher wrote:
>
>      >
>      > Also it probably shouldn't be returning subsections via symbols
>     as well.
>      >
>      > Anyhow, let's solve the original problem better :)
>
>     Soo... any ideas here?
>
>
> Sure. Looking through the code a bit...
>
> A) Rename getNoopForMacho to just getNoop. I don't think any of the nop
> codes are mach-o specific.
> B) The subsections via symbols thing there is important, as far as I
> know only darwin will actually fail if a function is empty (and that's
> only because the linker will just coalesce the two symbols and ditch one
> iirc).
> C) Reading the patch that put in RequiresNoop I think it's still an
> "only darwin" thing.
>
> At the very least gcc doesn't have a problem emitting:
>
> dzur:~/tmp> cat foo.c
> void f(void) {
>    __builtin_unreachable();
> }
>
> dzur:~/tmp> gcc -O3 -S -o - -fomit-frame-pointer foo.c
> .file"foo.c"
> .section.text.unlikely,"ax", at progbits
> .LCOLDB0:
> .text
> .LHOTB0:
> .p2align 4,,15
> .globlf
> .typef, @function
> f:
> .LFB0:
> .cfi_startproc
> .cfi_endproc
> .LFE0:
> .sizef, .-f
> .section.text.unlikely
> .LCOLDE0:
> .text
> .LHOTE0:
> .ident"GCC: (GNU) 4.9.0 20140310 (experimental)"
> .section.note.GNU-stack,"", at progbits
>
> and I think the FDE appears valid there. Which means that r108568 should
> be darwin only.
>
> So, ultimately, I think the correct fix is to make sure
> that HasAnyRealCode returns false for the testcases that r108568 was
> designed to work around, then remove the RequiresNoop bit from the
> conditional that was leading you down this path.
>
> How does this sound?

First thing that needs fixing is the crashing issue. From looking
around it seems as if EmitRawText() is not supposed to be used anymore
and yet I see it in use for the MC AsmPrinter, the NVPTX, XCore and
AArch64 backends too.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.