First of all, we were using the wrong size variable: instead of the size
of the section, found in the section header, we were using the size of
each section entry in the section table. Since that's usually smaller,
we weren't hitting a problem.
Second, if the string table is the last thing in the file and there's
nothing else after it, not even padding, then offset + section_size can
be equal to the file size. In fact, the .shstrtab section is usually the
last one, as it contains the section names themselves, so it stands to
reason that it's the second to last thing written.
For generic linkers, the last data in the file is the section table
itself, so usually the file is larger by at least a kilobyte, which is
why we haven't hit this bug. It could only manifest as deciding that
certain specially-crafted but valid ELF files were invalid. I can't
think of a way to trick it into thinking an invalid ELF is valid.
That's another reason why this code needs to be rewritten with more
modern coding styles and actually using <elf.h>
Fixes: QTBUG-71443
Change-Id: I1bd327aeaf73421a8ec5fffd156162f2df5557b8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The source is an ElfXX_Off, which is an unsigned 32- or 64-bit. That
means any section bigger than 2 GB would cause an overflow when we
assigned in
m_stringTableFileOffset = strtab.offset;
Change-Id: Ib47c56818178458a88b4fffd15546bd47a89894e
Fixes: QTBUG-70560
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Android doesn't like nor use RTLD_NODELETE
Tasnk-number: QTBUG-64654
Change-Id: I2d884bbf22a681cca592942eba84ba97327ba974
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
...not just the debug flag. The information is saved outside of the CBOR
map for two reasons:
1) removing the hack that depended on how QCborStreamWriter and
TinyCBOR internally work, allowing for the extra parameter to be
written directly. We wouldn't be able to use that hack anyway and would
have needed a further, uglier hack to encode a byte whose value we
don't know.
2) outside the map, this information can be parsed more quickly and
then we can discard any plugins we shouldn't actually load.
Since we're doing this for a flag, I decided to move the Qt version
there too for reason #2.
Change-Id: I61ecce6b1324410bbab4fffd153d4e5fc696d19e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
In preparation for Qt 6 deprecating the binary JSON format. Also reduces
the size of the metadata a little: for the xcb platform plugin, it went
down from 264 bytes to 138; for the jpeg image plugin, it went from 320
to 135.
I've had to change the signature so older versions of Qt won't try to
parse the CBOR data as Binary JSON. Unfortunately, before QJsonDocument
could get a chance to reject it, qJsonFromRawLibraryMetaData() needed to
allocate memory and that causes crashes with Qt < 5.11.2.
Change-Id: Ieb48f7c0dd0e4e0fb35efffd153bee34e16ce347
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Replace by reinterpret_cast or const_cast, respectively.
Use auto when initializing a variable to fix Clang warnings
about repeating the type name, do minor tidying along the way,
and a few conversions of 0 or NULL to nullptr.
Change-Id: Ieb271a87ddcf064f536e1ff05d23b1e688b1b56a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Eight bytes into the Binary JSON header there's a 32-bit little-endian
size, which qJsonFromRawLibraryMetaData uses to determine the size of
the stored metadata. That value is passed as a size to QByteArray, which
means certain values could cause crashes due to being too big or via
sign-extension in 64-bit.
[ChangeLog][QtCore][QPluginLoader] Fixed an issue that could cause a
crash when certain damaged or corrupt plugin files were scanned.
Change-Id: I117816bf0f5e469b8d34fffd153dc5425cec39a7
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
GCC5.4 generates incorrect code.
The QString object which is passed by value to f-lambda,
has been corrupted by the time this lambda returns.
Accessing this object causes memory corruption.
The same can be reproduced with std::list and std::string
Task-number: QTBUG-69394
Change-Id: I22522d2ddd1d5226de0aff378133d18391e370de
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I don't know why Arvid subtracted 1 when he wrote this code. But it was
wrong. Fortunately, the section size was not used afterwards, but the next
commit will.
Change-Id: I117816bf0f5e469b8d34fffd153dc8383b00b94a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When using actual memory allocation, limit to 64 MB, not the full file
size. On most systems, the memory map technique will work, so this won't
even be tried. In any case, we don't need the fix for the OOM situation
that was applied in commit e211ab76d7.
As for the memory mapping technique, this commit limits the allocation
to reasonable values given the virtual memory addressing space. Half a
gigabyte is probably acceptable on 32-bit systems, where there should be
a contiguous space for the OS to allocate the file in. This commit also
fixes an overflow when converting from qint64 of the file size to ulong
(32-bit on 32-bit platforms and on Windows).
For 64-bit systems, we currently limit to 1 TB.
Change-Id: I117816bf0f5e469b8d34fffd153dc1705a8eedc4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Libraries are placed in a subdir "haswell/" of the main library dir,
whereas plugins are simply named with ".avx2" appended to the plugin
name (plugin.so.avx2). The "haswell/" library directory suffix is a
convention found in glibc since version 2.26, whereas the ".avx2" and
".avx512" suffixes are a convention found in the Clear Linux OS for
Intel Architecture.
This patch implements this for all Unix OSes, except for Darwin, where
the fat file format already has a sub-architecture for Haswell
(x86_64h).
We could also implement the "sse2/" subdir search for libraries, but I
don't think it's worth the cost in 2018.
Change-Id: Iff4151c519c144d580c4fffd1539fe5ee9a4d7b1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use CamelCase, like the API they're tracing.
Change-Id: Ie718ab624d17c9186bcf05cc1276c8eccad7f454
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
RCC generates code that registers resources automatically on program
startup via global constructors. When linking statically and nothing
references the symbols in the .o file compiled from the RCC generated
code, then the linker will discard the embedded resources and they will
not get initialized. That is why for static linking it is necessary to
explicitly initialize resources using the Q_INIT_RESOURCE macro.
We can avoid the need for the explicit initialization in the context of
plugins that are statically linked into the application. resources.prf
can generate a .cpp file with a helper function that contains all the
Q_INIT_RESOURCE calls for all resources in the plugin. That helper
function in turn is injected into the plugin entry point, which in turn
is guaranteed to be included in the final binary.
Change-Id: If1abf9c85ef92935020af073b989c58c1ae6ca63
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
When Qt is configured for both debug and release, and frameworks are
enabled, we produce two dynamic libraries inside each framework, eg:
QtCore.framework/QtCore
QtCore.framework/QtCore_debug
When building an executable against these frameworks, we pass -framework
QtCore, and the resulting executable will have its LC_LOAD_DYLIB load
commands pointing to e.g.:
@rpath/QtCore.framework/Versions/5/QtCore
When running the executable, the dynamic loader will load the dynamic
library dependencies based on these load commands.
By setting the DYLD_IMAGE_SUFFIX environment variable at runtime to
'_debug', the dynamic loader will prefer the debug versions of each
library inside the frameworks.
Unfortunately the use of an environment variable to choose debug or
release versions leaves room for mismatches between the executable
and the libraries that are loaded. An executable built in debug
mode will at runtime pick up the release versions of the Qt libraries
unless the DYLD_IMAGE_SUFFIX has also been set to match the build
configuration of the executable.
This results in confusing situations such as building your application
in debug mode, and then stepping into Qt code but not getting any
symbols. Qt Creator has an option to run the application with
DYLD_IMAGE_SUFFIX set, but this is not enabled by default due
to the startup cost of loading the Qt debug libraries.
More critically, it results in tests failing when the tests are using
QTest::ignoreMessage to ignore warnings produced by Qt, and these
calls are ifdefed (correctly) inside QT_NO_DEBUG, as the test
(built in debug mode) will then expect warnings from Qt, but those
warnings are not emittet, as the test is run against the release
version of the Qt libraries.
To mitigate this mismatch, we now link the Qt frameworks using
an explicit suffix, just like we would for no-framework builds
on macOS, for debug and release builds on Windows, and for
normal builds on other Unixes, leaving the dependency chain
for the application predictable:
@rpath/QtCore.framework/Versions/5/QtCore_debug
This also conceptually matches how Xcode builds applications and
frameworks, where it never relies on DYLD_IMAGE_SUFFIX, and instead
uses two separate build directories, one for each configuration.
The change means that Qt Creator will always load the Qt debug
libraries if the application is built in debug mode. For Qt
development this is a good thing, as you expect to be able to
step into Qt code. For our users, the added startup cost can
be mitigated by shipping our binary packages as release-only,
but with separate debug info enabled.
Change-Id: Ib9f1f2dab90ed00b9fb011200e3a69c71955e399
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The only mkspecs that enabled QT_HPUX_LD were removed in ab44ac021d.
Change-Id: I9f27f0b487b69c11d19ba76801e3926b7894e6e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Conflicts:
src/corelib/tools/qvarlengtharray.qdoc
src/corelib/tools/qvector.qdoc
Resolved documentation changes in favor of 017569f702,
which keeps the move overloads along with its const-ref sibling.
Change-Id: I0835b0b3211a418e5e50defc4cf315f0964fab79
While we're at it, add a way to get it without the dashes too. I'm
calling it "id128", as in "128-bit ID", as seen in journald's sd_id128_t
type and the sd_id128_xxx() API.
[ChangeLog][QtCore][QUuid] Added a parameter to both toString() and
toByteArray() to allow controlling the use or not of the braces and
dashes in the string form.
Change-Id: I56b444f9d6274221a3b7fffd150cde706cfc5098
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This commit introduces minimal support for instrumentation within Qt.
Currently, only LTTNG/Linux and ETW/Windows are supported.
Change-Id: I59b48cf83acf5532a998bb493e6379e9177e14c8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A large plugin dll (e.g., one with many MB of debug info) could cause
a 32-bit application to crash when the entire dll file could not fit
within the address space of the process. The code for validating a
plugin library and retrieving metadata from it first tried to map
the entire file in memory, which failed for large files, returning
NULL. In this case, the code tried then to read the entire file via
QFile::readAll(), which deep below caused a bad_alloc exception in
malloc, resulting in the termination of the application. This change
handles the case where the library could not be mapped into memory,
in spite of memory mapping being supported, by reporting the error
and returning false, making the plugin unavailable.
[ChangeLog][QtCore][QPluginLoader] Fixed a bug that would cause the
Qt plugin scanning system to allocate too much memory and possibly
crash the process.
Task-number: QTBUG-65197
Change-Id: I8c7235d86175c9fcd2b87fcb1151570da9b9ebe3
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Clang needs to see a declaration for GUID, or it
will ignore some function declarations that must
be documented.
Change-Id: Ic5d5a88b82c709be7f763a44994b1c077977731a
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Right now,this does really nothing. This commit is just to allow us to
transition the other modules (besides qtbase) to use the syntax that
will become the API.
I've marked three places to use the system CSPRNG:
1) the QHash seed
2) QUuid
3) QAuthenticator
I didn't think the HTTP multipart boundary needed to be
cryptographically safe, so I changed that one to the global generator.
Change-Id: Ib17dde1a1dbb49a7bba8fffd14ecf1938bd8ff61
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
On Windows, qt_error_string() returns the string corresponding to the
Win32 API, not an errno. Replace those uses for a function that works
for errno values.
Change-Id: I1eba2b016de74620bfc8fffd14ccce6162bafdca
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QRandomGenerator can produce more than 31 bits of data. And it uses
/dev/urandom for us on Unix, so QHash does not need to duplicate that
part.
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b52a0d91f179eb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Compilation and link times in CPU seconds with GCC 7, using precompiled
headers (not including moc, rcc, uic, etc. steps or headersclean):
Before After
Debug -O0 198,1 180,3
Debug -Og 240,7 229,2
Release -O3 267,1 249,2
Release LTO 239,4 229,8
QtCore required a little manual adjusting because some files are
bootstrapped into moc itself and into qmake.
Change-Id: I84e363d735b443cb9beefffd14b8b57c10e7da36
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
As for the formatting code, de-duplicate the parsing code by only
parsing char*s, converting QChars to Latin-1 first in a small buffer.
The QUuid(const char*) ctor performed no length checking, relying
instead on the checks performed within _q_uuidFromHex(), which
includes an implicit check for premature end (because NUL is not
a valid token for the parser).
The (QString) and (QByteArray) ctors did perform length checking.
To the extent possible, this is removed, since it is handled by
_q_uuidFromHex(). Failure cases need not be optimized. Only the
QLatin1String overload needs to do some checking, because views in
general are not NUL-terminated. The QStringView overload can just
append a NUL when it converts to Latin-1.
The only check I added to _q_uuidFromHex() is that for src ==
nullptr. It would otherwise be duplicated in several callers.
While touching the internal functions, port to passing and returning
by value.
Saves 1.6KiB in text size on optimized GCC 6.1 Linux AMD64 builds,
even though we added new API.
Port some users to the new functions. Expand fromString() test.
[ChangeLog][QtCore][QUuid] Added fromString(QStringView/QLatin1String).
Change-Id: I519339419129550c86e0ea80514865cd6a768f5d
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The code was duplicated for QChar and char characters. Keep only the
char version, and use QString::fromLatin1() to convert to QString.
This does not perform more allocations. It just copies 38 bytes more
than before.
Saves 788B in text size on optimized GCC 6.1 Linux AMD64 builds.
Change-Id: I1a65c8128eb2097e11527961618d54ea362e1b80
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
... to reduce text size by replacing QStringLiteral with QL1S.
Change-Id: I8166282d915f081ba816989039451466ec29e208
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace it with QL1S in overloaded functions.
Saves some text size.
Change-Id: Ie1436a787fb3052157880234ca180fefce5a8412
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For the windows file system engine, we add an extra macro to use
library loading if configured to do so, but avoid it on WinRT, as
none of the symbols would be found.
We also QT_REQUIRE_CONFIG(library) in the library headers and
exclude the sources from the build if library loading is disabled.
This, in turn, makes it necessary to clean up some header inclusions.
Change-Id: I2b152cb5b47a2658996b6f4702b038536a5704ec
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
instead of having a library and a test, use a library with two sources,
the first being empty (i.e., just libc). this allows us doing away with
the "libdl" feature, and using just the "dlopen" one.
subsequently, replace all LIBS+=$$QMAKE_LIBS_DYNLOAD with
QMAKE_USE+=libdl.
the definitions of QMAKE_LIBS_DYNLOAD remain in the qmakespecs for
backwards compat only. n.b.: the only specs where it is not empty or
"-ldl" (i.e., what we support now) are the hpux ones, where the library
is called 'dld'.
technically, the "library" feature should depend on '!unix || dlopen', but
that's for a later patch.
Change-Id: Ib8546affc4b7bc757f1a76729573ddd00e152176
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is still not a great place for it, but this way we can
Q_REQUIRE_CONFIG(library) in qlibrary_p.h and qfactoryloader_p.h is the
only private header that doesn't require library support in plugin.pri.
Change-Id: Ia6c1ac8799822eca1e0cbeca98d1c1b8de74beae
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
A default-constructed static QBasicAtomicInt at function scope
will be dynamically initialized. It will still be zero-initialized,
but at least GCC adds guard variables for such objects.
When using aggregate initialization, the guard disappears.
Amends 04d6495bf7.
Change-Id: Id9335cffdd43094cafb231fdde2523d013abe1d6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The library feature already covers this. As library depends on the
dlopen compile check, we can assume dlopen to be available, also on
vxworks.
Change-Id: Idcdb07ab4688c6158651d9a5ad5e2ba126bd7d9e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Thiago Macieira
Liang Qi
BogDan Vatra
Friedemann Kleint
Edward Welbourne
Mikhail Svetkin
Qt Forward Merge Bot
Giuseppe D'Angelo
Simon Hausmann
Tor Arne Vestbø
Konstantin Tokarev
Rafael Roquetto
Andre de la Rocha
Lars Knoll
Martin Smith
Kevin Funk
Marc Mutz
Anton Kudryavtsev
Ulf Hermann
Oswald Buddenhagen