summaryrefslogtreecommitdiffstats
path: root/src/corelib/plugin/qmachparser.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QPlugin: pass the direct header to qJsonFromRawLibraryMetaData()Thiago Macieira2021-10-041-1/+5
| | | | | | | | This is done in preparation for storing the metadata without the magic string in static plugins and in ELF notes. Change-Id: I3eb1bd30e0124f89a052fffd16a820454dd56d3e Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QPlugin: simplify handling of exact results from Q{Elf,Mach}ParserThiago Macieira2021-10-041-2/+1
| | | | | | | | | | Those two scanners always return exact results, if the metadata is present, so we don't need to re-scan (haven't needed since Qt 5.0). Especially since we scan from the end, we were spending cycles doing unnecessary work. Change-Id: I42eb903a916645db9900fffd16a4ccfdc7342278 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Q{Elf,Mach}Parser: harmonize the arguments passedThiago Macieira2021-10-041-19/+18
| | | | | | | | | | | | | | Both functions took a QString for the input file name, but while the ELF parser had an optional QLibrary pointer (which was never null) where to store the error string, the Mach-O parser received a pointer to a QString. So make both of them take a single in/out QString pointer, which has the file name on input and is cheap for us because of COW. Drive-by fix the name of the static function in qmachparser.cpp from "ns" (which stood for "not suitable") to "notfound". Change-Id: I3eb1bd30e0124f89a052fffd16a8182f4f8541c3 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Q{Elf,Mach}Parser: simplify the return codesThiago Macieira2021-09-241-12/+8
| | | | | | | | | | | | | | | | | The multi-state return code was a legacy of how Arvid wrote the ELF parser code back in the day, the fact that it scanned for two different types of plugins in Qt 4 and that the metadata could exist in different places. None of that matters nowadays: who cares if the file is a corrupt binary, not a valid binary, does not have the right architecture, or has no suitable section? It's not a plugin, period. The Qt 4 plugin mechanism was removed for Qt 5.0 in commit 7443895857fdaee132c8efc643e471f02b3d0fa4 ("Remove support for Qt 4 style plugins"). Change-Id: I42eb903a916645db9900fffd16a442d800399b98 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Another round of replacing 0 with nullptrAllan Sandfeld Jensen2020-10-071-1/+1
| | | | | | | | | This time based on grepping to also include documentation, tests and examples previously missed by the automatic tool. Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QPluginLoader: limit the amount of memory used when scanning pluginsThiago Macieira2018-07-141-1/+1
| | | | | | | | | | | | | | | | | | | 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 e211ab76d766878b4dbe88901b9a7a4a70ce7332. 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>
* Use QT_CONFIG(library) instead of QT_NO_LIBRARYUlf Hermann2017-03-061-1/+1
| | | | | | | | | | | | | 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>
* Fix unimplemented Mach-O parsing for ARM64 platforms in QPluginLoader.Jake Petroules2016-05-301-0/+3
| | | | | Change-Id: I4853b5ce1691bd84578ebe46af9f73270598387a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update the Intel copyright yearThiago Macieira2016-01-211-1/+1
| | | | | | | | | Not that we require it, but since The Qt Company did it for all files they have copyright, even if they haven't touched the file in years (especially not in 2016), I'm doing the same. Change-Id: I7a9e11d7b64a4cc78e24ffff142b4c9d53039846 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Updated license headersJani Heikkinen2016-01-151-13/+19
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Update copyright headersJani Heikkinen2015-02-111-6/+6
| | | | | | | | | | | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Outdated header.LGPL removed (use header.LGPL21 instead) Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing combination. New header.LGPL-COMM taken in the use file which were using old header.LGPL3 (src/plugins/platforms/android/extract.cpp) Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license combination Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
* Update license headers and add new license filesMatti Paaso2014-09-241-18/+10
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 - Removed LICENSE.GPL Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2 Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
* Make the Mach-O size checking a little more robustThiago Macieira2013-07-201-20/+25
| | | | | | | | | | | | | | | | | It's not necessary to check at every point if we know the minimum file size: it must contain at least the header, one segment (__TEXT) and one section (qtmetadata). Most files have more than one segment and more than one loader command, so this check does not mean we can eliminate the checks further down. Also be more resilient against corruptions in the header data: check not only the additions, but the values themselves. For example, an offset + size addition could be smaller than the file size when the addition overflows in 32-bit. Another thing is that the cmdsize fields could be corrupt too. Change-Id: I7968a769c1cbe9150270c91823cafc4f8f833876 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Add a Mach-O decoder to the QPluginLoaderThiago Macieira2013-07-201-0/+213
We already had an ELF decoder, which helped us greatly to find the metadata and that catches most Unix systems (Solaris, QNX, HP-UXi, and all of the free Unixes). On other Unix systems, aside from Mac OS X, we simply scanned the entire file for the signature. On Windows, even without a COFF-PE decoder, we use a LoadLibrary trick to load the plugin without loading the dependent libraries. In most cases, that works. Unfortunately, on Mac OS X we didn't have a decoder and nor could we do the file scan: because Mac OS X binaries could be fat binaries, we wouldn't know which architecture's signature we had found. No more. This adds a full Mach-O decoder to QtCore. It is also capable of finding the boundaries of the architecture's binary, but that functionality is disabled since all Qt 5 plugins have plugin metadata sections. Change-Id: I2d5c04c5ecf024864b8a43f31ab6b7e6c5eae9ce Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>