With this change, the fuzzer-linker script should be specified outside
any --start-group/--end-group pairs. We need this on oss-fuzz, where
partially applying the linker-script results in a linker failure

Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
---
 meson.build                  | 9 ++++++++-
 tests/qtest/fuzz/meson.build | 1 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 74f8ea0c2e..a0407ce050 100644
--- a/meson.build
+++ b/meson.build
@@ -31,6 +31,14 @@ endforeach
 have_tools = 'CONFIG_TOOLS' in config_host
 have_block = have_system or have_tools
 
+# Specify linker-script with add_project_link_arguments so that it is not placed
+# within a linker --start-group/--end-group pair
+if 'CONFIG_FUZZ' in config_host
+   config_host += {'QEMU_LDFLAGS': config_host['QEMU_LDFLAGS'] +
+            ' -Wl,-T,' + (meson.current_source_dir() / 'tests/qtest/fuzz/fork_fuzz.ld')}
+endif
+
+
 add_project_arguments(config_host['QEMU_CFLAGS'].split(),
                       native: false, language: ['c', 'objc'])
 add_project_arguments(config_host['QEMU_CXXFLAGS'].split(),
@@ -1019,7 +1027,6 @@ foreach target : target_dirs
         'gui': false,
         'sources': specific_fuzz.sources(),
         'dependencies': specific_fuzz.dependencies(),
-        'link_depends': [files('tests/qtest/fuzz/fork_fuzz.ld')],
       }]
     endif
   else
diff --git a/tests/qtest/fuzz/meson.build b/tests/qtest/fuzz/meson.build
index bb0a3f271d..3432c3e7c3 100644
--- a/tests/qtest/fuzz/meson.build
+++ b/tests/qtest/fuzz/meson.build
@@ -10,7 +10,6 @@ specific_fuzz_ss.add(when: 'CONFIG_VIRTIO_SCSI', if_true: files('virtio_scsi_fuz
 # this will be duplicated in meson.build
 fork_fuzz = declare_dependency(
   link_args: ['-fsanitize=fuzzer',
-              '-Wl,-T,' + (meson.current_source_dir() / 'fork_fuzz.ld'),
               '-Wl,-wrap,qtest_inb',
               '-Wl,-wrap,qtest_inw',
               '-Wl,-wrap,qtest_inl',
-- 
2.28.0

On 02/09/20 16:37, Alexander Bulekov wrote:
> +# Specify linker-script with add_project_link_arguments so that it is not placed
> +# within a linker --start-group/--end-group pair
> +if 'CONFIG_FUZZ' in config_host
> +   config_host += {'QEMU_LDFLAGS': config_host['QEMU_LDFLAGS'] +
> +            ' -Wl,-T,' + (meson.current_source_dir() / 'tests/qtest/fuzz/fork_fuzz.ld')}
> +endif
> +
> +

Also -- sorry -- please use a separate add_project_link_arguments
invocation.

Paolo

On 02/09/20 16:37, Alexander Bulekov wrote:
> With this change, the fuzzer-linker script should be specified outside
> any --start-group/--end-group pairs. We need this on oss-fuzz, where
> partially applying the linker-script results in a linker failure

Is this okay also for targets that don't link to the fuzzing static library?

Paolo

On 200902 1745, Paolo Bonzini wrote:
> On 02/09/20 16:37, Alexander Bulekov wrote:
> > With this change, the fuzzer-linker script should be specified outside
> > any --start-group/--end-group pairs. We need this on oss-fuzz, where
> > partially applying the linker-script results in a linker failure
> 
> Is this okay also for targets that don't link to the fuzzing static library?
> 
> Paolo
> 

To be honest, I still do not completely understand why there is a
different behavior when we specify the script within a group. The man
page for ld.bfd doesn't talk about linker arguments between
--start-group and --end-group that are not archives. If I understand the
purpose of these linker groups, the linker script should still apply to
everything (regardless where it is specified). I would expect there to
be no change in behavior, or a complaint about passing linker arguments
that are not archive paths.

I was also worried about what would happen to all the __wrap_qtest
arguments, since those are still in the group, and they can fail silently.
Disassembling the binary confirmed that all the calls to
qtest_{in*,out*} are still wrapped.

Anyways.. I tested this series with and without LIB_FUZZING_ENGINE, and
used nm to confirm that the layout of the symbols/data is correct in
both cases (at least on my machine and the oss-fuzz docker) ..

-Alex