On 07.02.21 14:05, Andrea Bastoni wrote: > On 07/02/2021 11:20, Jan Kiszka wrote: >> On 25.01.21 13:00, Andrea Bastoni wrote: >>> Debugging is enabled by adding CONFIG_DEBUG in config.h >>> >>> Signed-off-by: Andrea Bastoni <[email protected]> >>> --- >>> hypervisor/include/jailhouse/assert.h | 37 +++++++++++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> create mode 100644 hypervisor/include/jailhouse/assert.h >>> >>> diff --git a/hypervisor/include/jailhouse/assert.h >>> b/hypervisor/include/jailhouse/assert.h >>> new file mode 100644 >>> index 00000000..eedb1b9f >>> --- /dev/null >>> +++ b/hypervisor/include/jailhouse/assert.h >>> @@ -0,0 +1,37 @@ >>> +/* >>> + * Runtime assert. >>> + * >>> + * Copyright (C) Technical University of Munich, 2020 >>> + * >>> + * Authors: >>> + * Andrea Bastoni <[email protected]> >>> + * >>> + * This work is licensed under the terms of the GNU GPL, version 2. See >>> + * the COPYING file in the top-level directory. >>> + */ >>> +#ifndef _ASSERT_H >>> +#define _ASSERT_H >>> + >>> +#ifndef CONFIG_DEBUG >>> +/* runtime assert does nothing in non-debug configurations */ >>> +#define assert(e) do { } while(0) >>> + >>> +#else >>> +extern void __assert_fail( >>> + const char *file, >>> + unsigned int line, >>> + const char *func, >>> + const char *expr) __attribute__((noreturn)); >>> + >>> +#define assert(e) \ >>> + do { \ >>> + if (e) { \ >>> + /* empty */ \ >>> + } else { \ >> >> Just if (!(e)) ... >> >> Or are you trying to emulate unlikely()? >> >>> + __assert_fail(__FILE__, __LINE__, __FUNCTION__, #e); \ >> >> assertion_failed(), and underscores aren't really needed. >> >> __FUNCTION__ is overkill. >> >>> + } \ >>> + } while (0) >>> + >>> +#endif /* CONFIG_DEBUG */ >>> + >>> +#endif >>> >> >> I'm including to make assert() work unconditional. People should not >> throw them mindlessly at the code but really at places where things >> could go subtly wrong and we better fail in a controlled manner. If >> assert() worked in debug mode only, the barrier to add it could be too low. > > I agree on not just throwing assert() mindlessly in the code, but I favor the > use of assert() as specification of a contract that can be checked at runtime. > > If e.g., due to restructuring in other parts of the code you cause a contract > to > be violated, you realize it quickly. In normal cases you want to have the > assertion only in testing, but, if you have an analysis phase of the code, you > could automatically transform the assertions into something that can be > checked > at analysis-time.
My argument against runtime contract checks at function entry is the low complexity of this code. I heard that "you must check all your inputs" from some safety veterans when they looked at the code and find nothing like that. But that is nonsense in most cases here specifically for local functions. And it leads to bad code structuring as well (you start to avoid factoring out functions as that creates interfaces). Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/23460976-58f9-67f9-f112-e84f179b8890%40siemens.com.
