Re: [PATCH] x86emul: rework wrapping of libc functions in test and fuzzing harnesses

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/08/2023 2:15 pm, Jan Beulich wrote:
> On 17.08.2023 14:58, Andrew Cooper wrote:
>> On 17/08/2023 12:47 pm, Jan Beulich wrote:
>>> Our present approach is working fully behind the compiler's back. This
>>> was found to not work with LTO. Employ ld's --wrap= option instead. Note
>>> that while this makes the build work at least with new enough gcc (it
>>> doesn't with gcc7, for example, due to tool chain side issues afaict),
>>> according to my testing things still won't work when building the
>>> fuzzing harness with afl-cc: While with the gcc7 tool chain I see afl-as
>>> getting invoked, this does not happen with gcc13. Yet without using that
>>> assembler wrapper the resulting binary will look uninstrumented to
>>> afl-fuzz.
>>>
>>> While checking the resulting binaries I noticed that we've gained uses
>>> of snprintf() and strstr(), which only just so happen to not cause any
>>> problems. Add a wrappers for them as well.
>>>
>>> Since we don't have any actual uses of v{,sn}printf(), no definitions of
>>> their wrappers appear (just yet). But I think we want
>>> __wrap_{,sn}printf() to properly use __real_v{,sn}printf() right away,
>>> which means we need delarations of the latter.
>>>
>>> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> This does resolve the build issue.  I do get a binary out of the end, so
>> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>.  I presume that
>> you've smoke tested the resulting binary?
> Oh, another question: Because of you asking it's not really clear whether
> the T-b is kind of implying an A-b as well. Could you confirm one way or
> the other, please?

Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>