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

[Jan Beulich <jbeulich@xxxxxxxx>]

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?

Jan