[llvm-dev] Using '__attribute__((section("name")))' for inline assembly injection

[Reid Kleckner via llvm-dev]

People also try to use
__attribute__((section(".mysection,\"rwx\", at progbits"))) to get executable
code sections for toy experiments in self-modifying code, but we don't
support that either. Basically, we take the section name and always quote
it, unlike GCC, and I don't think we want to change that. Normally LLVM
doesn't round trip through assembly, so it would be infeasible to attempt
to interpret strings in section names in all the ways that GCC allows
through to gas.

My advice for users in this situation would be to try the naked attribute
again, since we've fixed several bugs around it in the last two years. If
that doesn't work, adding a standalone assembly file to the project has
always been and will continue to be the most reliable way to implement a
function with a custom prologue.

On Wed, Oct 5, 2016 at 1:56 AM, Martin J. O'Riordan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I recently examined a bug in a program, and it turned out that the
> customer was using the section attribute as a form of inline-assembly
> mechanism, with something like:
>
>
>
> __attribute__((section(“sectionName\n*asm*\n*asm*\n*asm*”)))
>
>
>
> this was really ugly and not at all obvious where the problem originated.
> Is there any way of getting LLVM or CLang to validate the name used in the
> section attribute?  The GCC definition says that this only permits
> alpha-numeric characters, but I know that it is also very common for people
> to use ‘_’ and ‘.’ in section names so alpha-numeric checking is probably
> a bit over-zealous, but embedded newlines definitely should be considered
> suspicious.  Or perhaps there is an existing check in ‘clang-tidy’?
>
>
>
> The reason they were doing this in the first place, is that the ‘naked’
> attribute does not do what they want, which was to allow them to build
> custom prologue and epilogue code for a function.
>
>
>
> Thanks,
>
>
>
>             MartinO
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161005/8340ccdc/attachment.html>