Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Oct 22, 2023
  3. Oct 12, 2023
  5. Oct 11, 2023
  7. Oct 04, 2023
  9. Sep 21, 2023
  11. Sep 07, 2023
  13. Aug 31, 2023
  15. Jun 26, 2023
  17. Jun 06, 2023
    • Paolo Bonzini's avatar
      meson: subprojects: replace berkeley-{soft,test}float-3 with wraps · d2dfe0b5
      Paolo Bonzini authored 
      
Unlike other subprojects, these require an overlay directory to include
meson rules to build the libraries.  The rules are basically lifted
from tests/fp/meson.build, with a few changes to create platform.h
and publish a dependency.

The build defines are passed through a subproject option, and posted
back to users of the library via the dependency's compile_args.

The only remaining user of GIT_SUBMODULES and GIT_SUBMODULES_ACTION
is roms/SLOF, which is used to build pc-bios/s390-ccw.  All other
roms submodules are only present to satisfy the license on pre-built
firmware blobs.

Best reviewed with --color-moved.

Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d2dfe0b5
    • Paolo Bonzini's avatar
      meson: subprojects: replace submodules with wrap files · 2019cabf
      Paolo Bonzini authored 
      
Compared to submodules, .wrap files have several advantages:

* option parsing and downloading is delegated to meson

* the commit is stored in a text file instead of a magic entry in the
  git tree object

* we could stop shipping external dependencies that are only used as a
  fallback, but not break compilation on platforms that lack them.
  For example it may make sense to download dtc at build time, controlled
  by --enable-download, even when building from a tarball.  Right now,
  this patch does the opposite: make-release treats dtc like libvfio-user
  (which is not stable API and therefore hasn't found its way into any
  distros) and keycodemap (which is a copylib, for better or worse).

dependency() can fall back to a wrap automatically.  However, this
is only possible for libraries that come with a .pc file, and this
is not very common for libfdt even though the upstream project in
principle provides it; it also removes the control that we provide with
--enable-fdt={system,internal}.  Therefore, the logic to pick system
vs. internal libfdt is left untouched.

--enable-fdt=git is removed; it was already a synonym for
--enable-fdt=internal.

Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2019cabf
    • Paolo Bonzini's avatar
      configure: rename --enable-pypi to --enable-download, control subprojects too · ac4ccac7
      Paolo Bonzini authored 
      
The behavior of --{enable,disable}-pypi is similar to that of
-Dwrapmode={default,nodownload} respectively.  In particular,
in both cases a feature needs to be explicitly enabled for the
dependency to be downloaded.

So, use a single option to control both cases.  Now, --enable-slirp
will trigger cloning and building of libslirp if the .pc file
is not found on the machine.

Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      ac4ccac7
  19. May 26, 2023
  21. Apr 28, 2023
  23. Apr 21, 2023
  25. Apr 20, 2023
  27. Mar 03, 2023
    • Carlos López's avatar
      libvhost-user: check for NULL when allocating a virtqueue element · 9c191605
      Carlos López authored 
      
Check the return value for malloc(), avoiding a NULL pointer
dereference, and propagate error in function callers.

Found with GCC 13 and -fanalyzer:

../subprojects/libvhost-user/libvhost-user.c: In function ‘virtqueue_alloc_element’:
../subprojects/libvhost-user/libvhost-user.c:2556:19: error: dereference of possibly-NULL ‘elem’ [CWE-690] [-Werror=analyzer-possible-null-dereference]
 2556 |     elem->out_num = out_num;
      |     ~~~~~~~~~~~~~~^~~~~~~~~
  ‘virtqueue_alloc_element’: event 1
    |
    | 2554 |     assert(sz >= sizeof(VuVirtqElement));
    |      |     ^~~~~~
    |      |     |
    |      |     (1) following ‘true’ branch (when ‘sz > 31’)...
    |
  ‘virtqueue_alloc_element’: events 2-4
    |
    | 2555 |     elem = malloc(out_sg_end);
    |      |     ^~~~   ~~~~~~~~~~~~~~~~~~
    |      |     |      |
    |      |     |      (3) this call could return NULL
    |      |     (2) ...to here
    | 2556 |     elem->out_num = out_num;
    |      |     ~~~~~~~~~~~~~~~~~~~~~~~
    |      |                   |
    |      |                   (4) ‘elem’ could be NULL: unchecked value from (3)
    |

Signed-off-by: default avatarCarlos López <clopez@suse.de>
Message-Id: <20230210112514.16858-1-clopez@suse.de>
Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      9c191605
  29. Mar 02, 2023
  31. Jan 11, 2023
  33. Dec 21, 2022
  35. Nov 27, 2022
  37. Nov 12, 2022
    • Philippe Mathieu-Daudé's avatar
      libvduse: Avoid warning about dangerous use of strncpy() · 57bc6e40
      Philippe Mathieu-Daudé authored 
      
GCC 8 added a -Wstringop-truncation warning:

  The -Wstringop-truncation warning added in GCC 8.0 via r254630 for
  bug 81117 is specifically intended to highlight likely unintended
  uses of the strncpy function that truncate the terminating NUL
  character from the source string.

Here the next line indeed unconditionally zeroes the last byte, but
1/ the buffer has been calloc'd, so we don't need to add an extra
byte, and 2/ we called vduse_name_is_invalid() which checked the
string length, so we can simply call strcpy().

This fixes when using gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0:

  [42/666] Compiling C object subprojects/libvduse/libvduse.a.p/libvduse.c.o
  FAILED: subprojects/libvduse/libvduse.a.p/libvduse.c.o
  cc -m64 -mcx16 -Isubprojects/libvduse/libvduse.a.p -Isubprojects/libvduse -I../../subprojects/libvduse [...] -o subprojects/libvduse/libvduse.a.p/libvduse.c.o -c ../../subprojects/libvduse/libvduse.c
  In file included from /usr/include/string.h:495,
                   from ../../subprojects/libvduse/libvduse.c:24:
  In function ‘strncpy’,
      inlined from ‘vduse_dev_create’ at ../../subprojects/libvduse/libvduse.c:1312:5:
  /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 256 equals destination size [-Werror=stringop-truncation]
    106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  cc1: all warnings being treated as errors
  ninja: build stopped: cannot make progress due to previous errors.

Fixes: d9cf16c0 ("libvduse: Replace strcpy() with strncpy()")
Suggested-by: default avatarMarkus Armbruster <armbru@redhat.com>
Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: default avatarXie Yongji <xieyongji@bytedance.com>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Tested-by: default avatarBin Meng <bmeng@tinylab.org>
Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20221111124550.35753-1-philmd@linaro.org>
      57bc6e40
  39. Aug 02, 2022