[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 11/25] x86emul: place test blobs in executable section

>>> On 05.02.18 at 14:11, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/02/18 15:27, Jan Beulich wrote:
>>>>> On 02.02.18 at 14:03, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 07/12/17 14:06, Jan Beulich wrote:
>>>> This allows the section contents to be disassembled without going
>>>> through any extra hoops, simplifying the analysis of problems in test
>>>> and/or emulation code.
>>>> The blobs being emitted as (r/o) data means we need to accept an
>>>> assembler warning here (about the differing section attributes).
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> What about just giving up their constness?  This is a test program after
>>> all.
>> Then the conflict would be in two attributes (writable and
>> executable) rather than just one. The issue is that we emit them
>> as data, but want them to be in an executable section. If anything
>> we'd have to re-do how they're emitted (e.g. by using asm()), but
>> that seems overkill to me.
> Ok.  Instead, how about having a second .test.const? wouldn't that
> resolve the warnings, but still leave the instructions in an executable
> section?

Well, with just the above I can't see how you'd expect that to work:
Whatever we name the section that the const arrays are emitted to,
it'll have a section directive with just "a" as attributes. Somehow we'd
need to add the missing "x", and that would require a second section
directive. Which would trigger the very warning again.

Now we could of course have a second source file, but besides this
imo going too far, it would also have the downside that in the .o
we'd then again have a non-executable section containing code
(and which most tools won't easily disassemble).

> Either way, this is just a developer utility, so Acked-by: Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>

Thanks, Jan

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.