Oct 24 2018
Sep 5 2018
Added additional comments to clarify to the source code additions.
Added a setTargetSectionFlags virtual method to MCELFObjectTargetWriter and moved the logic that modifies the TextSection flags over to the ARMELFObjectWriter.
Aug 30 2018
Just to follow up on the earlier issue I mentioned where handwritten assembly sections named .text were not getting the execute-only flag applied ( D48792#1186500 ), it seems I was mistaken. Defining the section as below does result in the execute-only flags being set properly in the object file.
Thanks for the update. I still think this looks good to me.
I'm out of quick ideas for how to do this in a better way. The only other ways that I can think of are to not pre-create the .text section and create in on demand if needed; or find some way of deleting it afterwards. These may be possible but will be more disruptive. I think that this will handle the LTO case where the "link-step" clang invocation doesn't get passed the -fexecute-only flag, which IIRC was the main reason not to just create the TextSection with the execute-only flag in the first place based on the presence of -fexecute-only.
Aug 29 2018
Added a new check condition to test/CodeGen/ARM/execute-only.ll to make sure the bare ".text" section is not emitted in assembly output that should be execute-only.
I've added a couple of comments. One other thing to think about is the -S output from the compiler. If I compile a trivial test case with -mexecute-only I get the output:.text .syntax unified .eabi_attribute 67, "2.09" @ Tag_conformance ... .section .text,"axy",%progbits,unique,0 .globl func @ -- Begin function func ...
I'm not sure how easy it will be to change .text to .section .text, "axy", %progbits. In theory if this is assembled with MC and this patch it should come out with execute only (may be worth a test case). Re-assembling with GNU as will likely create a .text section without SHF_ARM_PURECODE but I don't think that this isn't likely enough in practice to worry too much about.
Aug 28 2018
Friendly ping for anyone familiar with the MC infrastructure to take a look at this. Thanks.
Aug 22 2018
Added the additional HasData property and check to see if data has been emitted to the .text section.
Aug 21 2018
Aug 14 2018
Aug 6 2018
I'll put together a separate patch (probably next week) for the .text assembly issue to keep this patch from growing more complicated, and to have the discussion in a dedicated thread. I've got an idea for how to handle it which basically boils down to passing execute-only to cc1as and making a couple changes to ARMAsmParser and MCTargetOptions, but there are some details that need to be hammered out still.
Aug 2 2018
The updated patch adds support for the case peter.smith brought up by checking for an empty .text section that's paired with SHF_ARM_PURECODE sections.
Jul 30 2018
If this looks good, could someone with commit access please land it? Thank you!
Jul 27 2018
Added the test to make sure that linker scripts are handled correctly. Also added a check against Script->HasSectionsCommand in checkOptions differentiate between Config->SingleRoRx being set via the command-line arg and being set via the script parser.
Added a check in finalizeSections() for intermingled data and executable sections. Also moved the computeFlags() check for ExecuteOnly to occur before the SingleRoRx check.
Jul 26 2018
As mentioned in my last comment, I'm disabling the execute-only flag when linker scripts with sections defined are used. This also changes the proposed flag from "aarch64-execute-only" to just "execute-only" and makes the suggested modifications to the test.
Jul 18 2018
Is this for compatibility with an existing option, or is this a new option? If this is new, I think -aarch64 prefix might be undesirable -- even though "execute only" pages are currently supported by AArch64 among major ISAs, I can imagine that other ISA could support it. So a more platform-neutral naming might be better.
Jul 17 2018
Jul 10 2018
This seems reasonable to me. I'll look into putting together an LLD patch that does this. Thanks!
Jul 3 2018
Yea this is what I'm seeing as well with the patched version unfortunately. I'll poke around the code and see if there's anywhere appropriate where we might be able to change the initial TextSection at a later stage.
Yea I wasn't sure exactly which approach to take here. Initially I thought that setting the TextSection to always include SHF_ARM_PURECODE was the way to go since I hadn't seen that section being used when generating object files from source. However I discovered from running the test suite that this section is used when assembling machine code and outputting an object-file with llvm-mc. This erroneously set the SHF_ARM_PURECODE flag when no execute-only flag was provided. This leads me to believe there may be other scenarios where this section is used as well.
Jun 29 2018
Passed an IR file to llc with a mix of functions that have the execute-only attribute set and ones that don't to test this. Two .text sections are generated in the object file, one with the SHF_ARM_PURECODE flag set and one without, and functions reside in their respective sections.
What happens if the input IR has a mix of execute-only and non-execute-only functions? Does the output .text section have the SHF_ARM_PURECODE flag?