VC runtime was substantially refactored on MSVC 14.0. Among other,
_tiddata structure defined in crt/src/mtdll.h was replaced with
__vcrt_getptd defined in crt/src/vcruntime/vcruntime_internal.h.
All members before
unsigned long _NLG_dwCode
were removed, so that the approach to access the member
void * _tpxcptinfoptrs; /* ptr to exception info pointers */
with __pxcptinfoptrs() and compute the offset to the _curexception
member of _tiddata doesn't work on MSVC 14.0.
As of MSVC 14.0 __vcrt_getptd symbol isn't exported but Microsoft
have introduced methods to access current exception, current exception
context and processing throw (the later can be accessed through C++17
std::unhandled_exceptions() that was made available in MSVC 14.0):
* __current_exception()
* __current_exception_context()
* __processing_throw() aka std::unhandled_exceptions()
Make use of __current_exception() which we can hope will be maintained
going forward.
Change-Id: Ibfffa5fba62d6928328ac976cb1b24937277363e
Reviewed-on: https://gerrit.libreoffice.org/18475
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
In bridges/source/cpp_uno/gcc3_macosx_x86-64/share.hxx, the #if also covered
Clang, which actually needs these declarations (for now; the right fix will
probably be to #include <cxxabi.h>).
Change-Id: I1eebd59e2371f3498d740ab78244927358c4f23f
Some versions of gcc clobber one of the registries that are used to pass
arguments in the function's prologue, like:
Dump of assembler code for function (anonymous namespace)::privateSnippetExecutor():
510 {
0x00003fffaffe8454 <+0>: mflr r0
0x00003fffaffe8458 <+4>: std r0,16(r1)
0x00003fffaffe845c <+8>: std r29,-24(r1)
0x00003fffaffe8460 <+12>: std r30,-16(r1)
0x00003fffaffe8464 <+16>: std r31,-8(r1)
0x00003fffaffe8468 <+20>: stdu r1,-352(r1)
0x00003fffaffe846c <+24>: mr r31,r1
=> 0x00003fffaffe8470 <+28>: ld r8,-28688(r13)
0x00003fffaffe8474 <+32>: std r8,312(r31)
0x00003fffaffe8478 <+36>: li r8,0
Reading the registries through variables makes gcc aware that they are
used, so it does not touch them. It has got no negative effect on
performance, as it produces the same object code as the current asm
block.
Change-Id: I3b99b0aa9944f9f33de9a42508e9d4dd23cec5e0
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx>
(and don't make use of it themselves), but many other files happen to depend on
it. Cleaned up some, but something like
grep -FwL sal/log.hxx $(git grep -Elw \
'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF') -- \*.cxx)
shows lots more files that potentially need fixing before the include can be
removed from rtl/string.hxx and rtl/ustring.hxx.
Change-Id: Ibf033363e83d37851776f392dc0b077381cd8b90
ie.
void f(void);
becomes
void f();
I used the following command to make the changes:
git grep -lP '\(\s*void\s*\)' -- *.cxx \
| xargs perl -pi -w -e 's/(\w+)\s*\(\s*void\s*\)/$1\(\)/g;'
and ran it for both .cxx and .hxx files.
Change-Id: I314a1b56e9c14d10726e32841736b0ad5eef8ddd
...similarly to 0fdbb5b0eabbaa571f3747fda12a56c938cba474 "Make
cpp_uno/gcc3_linux_x86-64 bridge work with GCC 4.7"
Change-Id: Idcafcb07678d02446172d7fde30631a342f6437e
...when write+exec mmap fails (due to SELinux deny_execmem). This avoids the
tmp file creation in environments that don't need it and which in turn have
problems of their own with that tmp file business.
An alternative would be to first check whether SELinux deny_execmem is enforced
and only then try double mmap first. An advantage could be that it might avoid
false SELinux alerts in that case. The disadvantage would be the overhead of
introducing a conditional dependency on libselinux here. And given that for one
deny_execmem typically appears to be off by default (as at least both
contemporary GNOME desktop and OpenJDK malfunction when it is enabled), and for
another I guess deny_execmem could still change its value between the time of
checking for it and the time of requesting a write+exec mmap, that just does not
seem worth it.
Change-Id: I3560803139b630557b6219d3db52945c7e0cdcd2
