Clang-15 (as seen in the FreeBSD 14 tests) complains:
xg_main.c:1248 error: a function declaration without a
prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
xg_init()
^
void
The error message is a bit confusing but appears to new as part of
-Wdeprecated-non-prototype which is part of supporting C2x which formally
removes K&R syntax.
Either way, fix the identified function.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
gdbsx/:
- Make use of subdir facility for the "clean" target.
- No need to remove the *.a, they aren't in this dir.
- Avoid calling "distclean" in subdirs as "distclean" targets do only
call "clean", and the "clean" also runs "clean" in subdirs.
- Avoid the need to make "gx_all.a" and "xg_all.a" in the "all"
recipe by forcing make to check for update of "xg/xg_all.a" and
"gx/gx_all.a" by having "FORCE" as prerequisite. Now, when making
"gdbsx", make will recurse even when both *.a already exist.
- List target in $(TARGETS).
gdbsx/*/:
- Fix dependency on *.h.
- Remove some dead code.
- List targets in $(TARGETS).
- Remove "build" target.
- Cleanup "clean" targets.
- remove comments about the choice of "ar" instead of "ld"
- Use "$(AR)" instead of plain "ar".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
"make distclean" will complain that "-c" is no supported flag for make.
Fix that by using "-C".
The error has been present for a long time, but it was uncovered only
recently.
Fixes: 2400a9a365 ("tools/debugger: Allow make to recurse into debugger/")
Fixes: f9c9b12775 ("tools: fix make distclean")
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Tested-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
On NetBSD the privcmd interface node is /kern/xen/privcmd
Signed-off-by: Manuel Bouyer <bouyer@netbsd.org>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Doing so isn't appropriate here - this gets done very early in the build
process. If the directory is mean to to be buildable on its own,
different arrangements would be needed.
The issue has become more pronounced by 47654a0d73 ("tools/include:
fix (drop) dependencies of when to populate xen/"), but was there before
afaict.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
gdb 8.0 fixed bounds checking for 'g' packet (commit
9dc193c3be85aafa60ceff57d3b0430af607b4ce "Check for truncated
registers in process_g_packet"). This revealed that gdbsx did
not properly formatted 'g' packet - segment registers and eflags are
expected to be 32-bit fields in the response (according to
gdb/features/i386/64bit-core.xml in gdb sources). Specific error is:
Truncated register 26 in remote 'g' packet
instead of silently truncating part of register.
Additionally, it looks like segment registers of 64bit guests were never
reported correctly, because of type mismatch.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Currently building gdbsx with clang 3.8 gives the following errors:
xg_main.c:783:17: error: 'aligned' attribute ignored when parsing type [-Werror,-Wignored-attributes]
iop->uva = (uint64_aligned_t)((unsigned long)tobuf);
^~~~~~~~~~~~~~~~
/builds/liuw/xen/tools/debugger/gdbsx/xg/../../../../tools/include/xen/arch-x86/xen-x86_32.h:105:50: note: expanded from macro 'uint64_aligned_t'
^~~~~~~~~~
xg_main.c:816:17: error: 'aligned' attribute ignored when parsing type [-Werror,-Wignored-attributes]
iop->uva = (uint64_aligned_t)((unsigned long)frombuf);
^~~~~~~~~~~~~~~~
/builds/liuw/xen/tools/debugger/gdbsx/xg/../../../../tools/include/xen/arch-x86/xen-x86_32.h:105:50: note: expanded from macro 'uint64_aligned_t'
According to https://bugs.llvm.org/show_bug.cgi?id=11071, this issue has
been fixed in clang. But we're not going to get that in 3.8.
Explicitly disable that warning to fix the build.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
gcc-8 complains:
gx_main.c: In function 'prepare_stop_reply':
gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy(buf, "watch:", 6);
^~~~~~~~~~~~~~~~~~~~~~~~~
Since terminating '\0' isn't needed here at all, switch to memcpy.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-Acked-by: Juergen Gross <jgross@suse.com>
Running "make uninstall" does not remove all installed files, a
situation which might cause link related issues if xen is re-installed
in a different location.
In order to make uninstall correctly remove the files it is best
the process should be done recursively by mirroring each "install"
target with an "uninstall" who removes the installed files.
An exception to this rule is uninstalling the files produced by
"qemu-xen-dir-remote" and "qemu-xen-traditional-dir", which are external
to the project. These projects do not implement an "uninstall" target so
the files have to be removed manually.
Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Currently __XEN_TOOLS__ is defined in the global CFLAGS used for tools
builds, exposing them all to the various unstable hypercall interfaces.
However there are places where we do not want this (in particular all
the stable libraries now under tools/libs), and there is a risk of
such uses slipping in unnoticed (currently there are none, but I
tripped over the mixed nature of the HVMOPs just now in some new code
I was putting together).
Instead only define __XEN_TOOLS__ for things which explicitly want the
unstable APIs. The vast majority of these are consumers of libxenctrl,
which have opted into unstable interfaces by using libxenctrl already,
so adding -D__XEN_TOOLS__ to CFLAGS_libxenctrl covers these without
needing to patch the dozen or so tools manually.
The libxc build itself, which doesn't use CFLAGS_libxenctrl, now needs
the define too. As does gdbsx's own low level hypercall binding
library xg.
hvmloader no longer needs to undefine the symbol.
The ocaml evtchn bindings don't actually need sysctl.h and therefore
don't actually need __XEN_TOOLS__ either.
qemu-xen-traditional doesn't use CFLAGS_libxenctrl and so we pass the
define there (via --extra-cflags) too.
Having removed __XEN_TOOLS__ replace it with
__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ so that in
tree code is always using the latest APIs.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
As recommended in http://www.gnu.org/licenses/gpl-howto.en.html.
This is the result of:
$ git grep -El Mass\|Temple\|Franklin | xargs ./fsf.pl
Where fsf.pl is:
#!/usr/bin/perl -w -pi.bak -0777
my $repl = 'If not, see <http://www.gnu.org/licenses/>.';
my $br = qr/(?:\s*\n\s*(?:[\*\#]|\/\/|\.\\" )?\s*|\s+)/;
my $inwt = qr/[Ii]f${br}not,${br}write${br}(?:to${br})?the${br}Free${br}Software${br}Foundation,(?:${br}Inc\.,)?/;
my $mass = qr/675${br}Mass${br}Ave,?${br}Cambridge,?${br}MA${br}02139,?${br}USA,?\.?/;
my $franklin = qr/51${br}Franklin${br}St(?:reet)?(?:,${br}| - )Fifth${br}Floor,?${br}Boston,?${br}MA,?${br}02110-1301,?${br}USA,?\.?/;
my $temple = qr/59${br}Temple${br}Place(?:,${br}| - )Suite${br}330,?${br}Boston,?${br}MA,?${br}021110?-1307,?${br}USA,?\.?/;
s|$inwt$br$mass|$repl|m;
s|$inwt$br$franklin|$repl|m;
s|$inwt$br$temple|$repl|m;
The only remaining mentions of these addresses are in COPYING files which I
haven't touched.
Some of the changed files are imports from elsewhere, however
filtering them out is tricky, I think it is tolerable to have these
files be modified here and then perhaps reverted on the next sync,
since it's only 1-2 lines and obvious what is going on.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
The original rule to target "distclean" in tools/Rules.mk was in effect
"make clean". It should be "make distclean".
However not all Makefiles in subdirectories have distclean target
defined. So this patch also adds a bunch of distclean targets to various
Makefiles. They only depend on clean target and don't have any actions
in most cases.
With the patch applied, following command outputs 0 results:
find tools -name 'Makefile*' -exec grep -L 'distclean' {} \+ \
| grep -v ocaml | grep -v libfsimage
Ocaml and libfsimage are known to have distclean defined in a dedicated
rules file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Without this gdb does not report an error.
With this patch and using a 1G hvm domU:
(gdb) x/1xh 0x6ae9168b
0x6ae9168b: Cannot access memory at address 0x6ae9168b
Drop output of iop->remain because it most likely will be zero.
This leads to a strange message:
ERROR: failed to read 0 bytes. errno:14 rc:-1
Add address to write error because it may be the only message
displayed.
Note: currently XEN_DOMCTL_gdbsx_guestmemio does not change 'iop' on
error and so iop->remain will be zero.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
I had coded this with XGERR, but gdb will try to read memory without
a direct request from the user. So the error message can be confusing.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.
conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.
config.h is only used by libxl/xl to detect yajl_version.h.
[ tools/config.sub and config.guess copied from
autotools-dev 20100122.1 from Debian squeeze i386,
which is GPLv2.
tools/configure generated using the included ./autogen.sh
which ran autoconf 2.67-2 from Debian squeeze i386. autoconf
is GPLv3+ but has a special exception for the autoconf output;
this exception applies to us and exempts us from complying
with GPLv3+ for configure, which is good as Xen is GPL2 only.
- Ian Jackson ]
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
It's not needed unless you are including headers in the current
directory _and_ you can't use "" instead of <> because the headers are
to be installed.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Several places include it in CFLAGS even though it is never defined. A
few others use it as nothing more than a gathering point for
CFLAGS. Get rid of it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
Not checking leads to warn_unused_result checks triggering in some
libraries and compilers. Combined with -Werror this breaks the build.
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
gdbsx hacks CFLAGS to remove optimisations for easier debugging, however
this breaks dep generation due to an early evaluation of CFLAGS and
leaves stale files called "..d" after a make clean. We could possibly
fix this by separating dep generation from the rest of CFLAGS but it
seems a little invasive. The gdbsx hackers can do their own thing during
development and testing anyway...
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
The attached patch first tries the MTF flag for HVM guest
single step, reverting to manually setting the TF flag if MTF fails.
Tested on 4.0.1. Compile tested on unstable.
Signed-off-by: mukesh.rathor@oracle.com
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Newer version of gdb, version 7*, seems to have bug where it is not
parsing thread list from gdbsx properly. Getting rid of the space in
thread list works around it. It's ok with older gdb also.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
It should be run on dom0 on gdbsx enabled hypervisor. For details,
please see tools/debugger/gdbsx/README
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Andrew Cooper