>>> On 05.02.18 at 14:11, <andrew.coop...@citrix.com> wrote: > On 02/02/18 15:27, Jan Beulich wrote: >>>>> On 02.02.18 at 14:03, <andrew.coop...@citrix.com> 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 <jbeul...@suse.com> >>> 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.coop...@citrix.com> Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
