| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This allows us to disable Unix sockets cleanly on Windows. Replaces some
read/write calls with recv/send counterparts, as Winsock does not like
read/writes.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The _s variants and friends do not seem to work on Windows 7 and always fail.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While DbgHelp provides a convenient API to create backtraces, any executable
linking against DbgHelp gets a more than a significant slow down. Further, it
can only lookup global symbols, as it expects PDB files we can't produce with a
MinGW build.
With some core Kernel32.dll functionality, we can capture stack traces much
faster. Together with the optional libbfd, we can print very fine backtraces.
When --enable-bfd-backtraces is used on Windows, a libbfd.dll is required for
the build. Such a DLL can be created from the binutils sources using:
# build binutils with mingw...
# extract archive members from binutils libraries
x86_64-w64-mingw32-ar x $BINUTILS/bfd/.libs/libbfd.a
x86_64-w64-mingw32-ar x $BINUTILS/intl/libintl.a
x86_64-w64-mingw32-ar x $BINUTILS/libiberty/libiberty.a
# create self-contained libbfd.a, with index
x86_64-w64-mingw32-ar qs libbfd.a *.o
# create DLL from static library
x86_64-w64-mingw32-dlltool -e libbfd.o -l libbfd.lib libbfd.a
x86_64-w64-mingw32-gcc -shared libbfd.a libbfd.o -o libbfd.dll
|
| |
|
| |
|
|
|
|
| |
We might extend it in the future using some Windows rights management.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Include some more basic system headers in utils.h, so we can use that common
header on the different platforms.
|
|
|
|
|
|
|
|
|
|
|
| |
Handling the result for enum_from_name() is difficult, as checking for
negative return values requires a cast if the enum type is unsigned. The new
signature clearly differentiates lookup result from lookup value.
Further, this actually allows to convert real -1 enum values, which could not
be distinguished from "not-found" and the -1 return value.
This also fixes several clang warnings where enums are unsigned.
|
|
|
|
|
| |
To allow enum.h to depend on utils.h definitions, avoid its direct inclusion.
Instead include utils.h, which includes enum.h as well.
|
| |
|
| |
|
| |
|
|
|
|
| |
Basically reintroducing 2a38b4556e9fd8102bd6c6c61f2893599a5e8e51.
|
| |
|
| |
|
|
|
|
|
|
| |
Using the same mechanism as the METHOD macro, the CALLBACK macro defines
a hybrid function signature. It strictly uses a weak void* for the first
function parameter, in contrast to the dynamic METHOD object "this" type.
|
|
|
|
|
|
|
|
|
|
|
| |
This solves a problem with GNAT when compiling charon-tkm as __atomic*
built-ins are only provided in GCC 4.7 and newer.
Currently GNAT 4.6 and GCC 4.7.2 is shipped with Debian wheezy (stable),
as used in the testing environment. So while the configure script correctly
detected the __atomic* built-ins, and defined HAVE_GCC_ATOMIC_OPERATIONS,
this define turned out to be incorrect when charon-tkm was later built
with GNAT.
|
|
|
|
|
|
|
|
| |
These are available since GCC 4.7 and will eventually replace the __sync
operations. They support the memory model defined by C++11. For instance,
by using __ATOMIC_RELAXED for some operations on the reference counters we
can avoid memory barriers, which are required by __sync operations (whose
memory model essentially is __ATOMIC_SEQ_CST).
|
|
|
|
|
|
|
|
|
|
| |
On many architectures it is safe to read the value directly (those
using cache coherency protocols, and with atomic loads for 32-bit
values) but it is not if that's not the case or if we ever decide to
make refcount_t 64-bit (load not atomic on x86).
So make sure the operation is actually atomic and that users do not
have to care about the size of refcount_t.
|
|
|
|
|
| |
If lib->leak_detective is non-null some code parts (e.g. the plugin
loader) assume LD is actually used.
|
|
|
|
|
|
|
| |
The addresses can actually change as plugins are loaded/unloaded for
each test case.
Fixes #551.
|
|
|
|
|
| |
In some situations we expect strongswan.conf to not exist, for instance,
when running the unit tests before installation.
|
|
|
|
|
| |
This makes the tests work with clang, which does not implement said
builtin.
|
|
|
|
| |
This avoids any clashes with existing functions in the monolithic build.
|
|
|
|
|
|
|
|
| |
Because GCC does not adhere to the priorities defined for constructors
when building with --enable-monolithic (not sure if it was just luck
that it worked in non-monolithic mode - anyway, it's not very portable)
function registration would fail because the hashtable would not be
created yet.
|
|
|
|
| |
Closes #539.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A valgrind analysis of libstrongswan revealed an invalid read of 1 in
the function starts_with(). A more thorough analysis proved this to be
true and showed that with a specially crafted config file (e.g. a single
'#'-character not followed by a newline), the parser might even
interpret the random memory contents following the allocated buffer as
part of the configuration file.
The way the parser is designed, it must be able to skip an inserted
'\0' and continue parsing. Since it is not able to skip two '\0'
characters, the 'fix' of allocating two more bytes than the size of the
parsed file and setting them to '\0' seems to be a safe bet.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
| |
For instance, on Mac OS X memrchr(3) is not provided by the C library.
|
| |
|
| |
|
|
|
|
|
| |
For some utils _GNU_SOURCE might be needed but that conflicts with the
signature of strerror_r(3).
|
|
|
|
|
|
|
|
| |
dirname(3) may return a pointer to a statically allocated buffer.
So freeing the returned value can result to undefined behavior. This was
noticed on FreeBSD where it caused very strange crashes.
It is also not thread-safe, which will be addressed later.
|