aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-size
AgeCommit message (Collapse)AuthorFilesLines
11 days[llvm-size] Fix --totals option for Mach-O files (#157904)Ryan Mansfield1-10/+33
The --totals option was not working for Mach-O files because the Darwin segment size calculation skipped the totals accumulation. --------- Co-authored-by: James Henderson <James.Henderson@sony.com>
2025-02-24[llvm-size] Initialize Radix to correct value (#128447)Vitaly Buka1-1/+1
Without the patch, invalid --radix, makes Radix to be 0, and result in invalid format specifier ` %#7 `, instead of e.g ` %#7x `.
2024-12-11Rework the `Option` library to reduce dynamic relocations (#119198)Chandler Carruth1-6/+10
Apologies for the large change, I looked for ways to break this up and all of the ones I saw added real complexity. This change focuses on the option's prefixed names and the array of prefixes. These are present in every option and the dominant source of dynamic relocations for PIE or PIC users of LLVM and Clang tooling. In some cases, 100s or 1000s of them for the Clang driver which has a huge number of options. This PR addresses this by building a string table and a prefixes table that can be referenced with indices rather than pointers that require dynamic relocations. This removes almost 7k dynmaic relocations from the `clang` binary, roughly 8% of the remaining dynmaic relocations outside of vtables. For busy-boxing use cases where many different option tables are linked into the same binary, the savings add up a bit more. The string table is a straightforward mechanism, but the prefixes required some subtlety. They are encoded in a Pascal-string fashion with a size followed by a sequence of offsets. This works relatively well for the small realistic prefixes arrays in use. Lots of code has to change in order to land this though: both all the option library code has to be updated to use the string table and prefixes table, and all the users of the options library have to be updated to correctly instantiate the objects. Some follow-up patches in the works to provide an abstraction for this style of code, and to start using the same technique for some of the other strings here now that the infrastructure is in place.
2024-09-13[llvm-size] Avoid unneeded uses of 'raw_string_ostream::str' (NFC) (#108490)Youngsuk Kim1-16/+15
Remove unnecessary layer of indirection.
2024-01-11[llvm-driver] Fix usage of `InitLLVM` on Windows (#76306)Alexandre Ganea1-2/+0
Previously, some tools such as `clang` or `lld` which require strict order for certain command-line options, such as `clang -cc1` or `lld -flavor`, would not longer work on Windows, when these tools were linked as part of `llvm-driver`. This was caused by `InitLLVM` which was part of the `*_main()` function of these tools, which in turn calls `windows::GetCommandLineArguments`. That function completly replaces argc/argv by new UTF-8 contents, so any ajustements to argc/argv made by `llvm-driver` prior to calling these tools was reset. `InitLLVM` is now called by the `llvm-driver`. Any tool that participates in (or is part of) the `llvm-driver` doesn't call `InitLLVM` anymore.
2023-08-04[llvm] Extract common `OptTable` bits into macrosJan Svoboda1-10/+2
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OPT_##ID`), kind (`Option::KIND##Class`), group ID (`OPT_##GROUP`) and alias ID (`OPT_##ALIAS`). This patch extracts that common code into canonical macros. This results in fewer changes when tweaking the `OPTION` macros emitted by the TableGen backend. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D157028
2023-02-10[llvm-driver] Pass extra arguments to toolsAlex Brachet1-1/+2
Differential Revision: https://reviews.llvm.org/D137799
2023-01-12[OptTable] Precompute OptTable prefixes union table through tablegenserge-sans-paille1-2/+2
This avoid rediscovering this table when reading each options, providing a sensible 2% speedup when processing and empty file, and a measurable speedup on typical workloads, see: This is optional, the legacy, on-the-fly, approach can still be used through the GenericOptTable class, while the new one is used through PrecomputedOptTable. https://llvm-compile-time-tracker.com/compare.php?from=4da6cb3202817ee2897d6b690e4af950459caea4&to=19a492b704e8f5c1dea120b9c0d3859bd78796be&stat=instructions:u Differential Revision: https://reviews.llvm.org/D140800
2022-12-27[clang] Use a StringRef instead of a raw char pointer to store builtin and ↵serge-sans-paille1-1/+4
call information This avoids recomputing string length that is already known at compile time. It has a slight impact on preprocessing / compile time, see https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470. The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e. The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable. Differential Revision: https://reviews.llvm.org/D139881
2022-12-25Revert "[clang] Use a StringRef instead of a raw char pointer to store ↵Vitaly Buka1-4/+1
builtin and call information" Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)" Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4" GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104 compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0. This reverts commit caa713559bd38f337d7d35de35686775e8fb5175. This reverts commit 06b90e2e9c991e211fecc97948e533320a825470. This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
2022-12-24[clang] Use a StringRef instead of a raw char pointer to store builtin and ↵serge-sans-paille1-1/+4
call information This avoids recomputing string length that is already known at compile time. It has a slight impact on preprocessing / compile time, see https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 that into account a GGC issue (probably https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181) when dealing with intiailizer_list and constant expressions. Workaround this by avoiding initializer list, at the expense of a temporary plain old array. Differential Revision: https://reviews.llvm.org/D139881
2022-12-23Revert "[clang] Use a StringRef instead of a raw char pointer to store ↵serge-sans-paille1-3/+2
builtin and call information" There are still remaining issues with GCC 12, see for instance https://lab.llvm.org/buildbot/#/builders/93/builds/12669 This reverts commit 5ce4e92264102de21760c94db9166afe8f71fcf6.
2022-12-23[clang] Use a StringRef instead of a raw char pointer to store builtin and ↵serge-sans-paille1-2/+3
call information This avoids recomputing string length that is already known at compile time. It has a slight impact on preprocessing / compile time, see https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 with a change to llvm/utils/TableGen/OptParserEmitter.cpp to cope with GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Differential Revision: https://reviews.llvm.org/D139881
2022-12-23Revert "[clang] Use a StringRef instead of a raw char pointer to store ↵serge-sans-paille1-3/+2
builtin and call information" Failing builds: https://lab.llvm.org/buildbot#builders/9/builds/19030 This is GCC specific and has been reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 This reverts commit 719d98dfa841c522d8d452f0685e503538415a53.
2022-12-23[clang] Use a StringRef instead of a raw char pointer to store builtin and ↵serge-sans-paille1-2/+3
call information This avoids recomputing string length that is already known at compile time. It has a slight impact on preprocessing / compile time, see https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u Differential Revision: https://reviews.llvm.org/D139881
2022-12-20[Support] Move TargetParsers to new componentArchibald Elliott1-0/+1
This is a fairly large changeset, but it can be broken into a few pieces: - `llvm/Support/*TargetParser*` are all moved from the LLVM Support component into a new LLVM Component called "TargetParser". This potentially enables using tablegen to maintain this information, as is shown in https://reviews.llvm.org/D137517. This cannot currently be done, as llvm-tblgen relies on LLVM's Support component. - This also moves two files from Support which use and depend on information in the TargetParser: - `llvm/Support/Host.{h,cpp}` which contains functions for inspecting the current Host machine for info about it, primarily to support getting the host triple, but also for `-mcpu=native` support in e.g. Clang. This is fairly tightly intertwined with the information in `X86TargetParser.h`, so keeping them in the same component makes sense. - `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains the target triple parser and representation. This is very intertwined with the Arm target parser, because the arm architecture version appears in canonical triples on arm platforms. - I moved the relevant unittests to their own directory. And so, we end up with a single component that has all the information about the following, which to me seems like a unified component: - Triples that LLVM Knows about - Architecture names and CPUs that LLVM knows about - CPU detection logic for LLVM Given this, I have also moved `RISCVISAInfo.h` into this component, as it seems to me to be part of that same set of functionality. If you get link errors in your components after this patch, you likely need to add TargetParser into LLVM_LINK_COMPONENTS in CMake. Differential Revision: https://reviews.llvm.org/D137838
2022-12-08Store OptTable::Info::Name as a StringRefserge-sans-paille1-1/+1
This is a recommit of 8ae18303f97d5dcfaecc90b4d87effb2011ed82e, with a few cleanups. This avoids implicit conversion to StringRef at several points, which in turns avoid redundant calls to strlen. As a side effect, this greatly simplifies the implementation of StrCmpOptionNameIgnoreCase. It also eventually gives a consistent, humble speedup in compilation time (timing updated since original commit). https://llvm-compile-time-tracker.com/compare.php?from=de4b6a1bc64db33643f001ad45fae7b92b4a4688&to=c23a93d1292052b4be2fbe8c586fa31143d0c7ed&stat=instructions:u Differential Revision: https://reviews.llvm.org/D139274
2022-10-06[llvm-driver] Add various tools to the llvm-driverAlex Brachet2-1/+3
The llvm-driver, enabled with LLVM_TOOL_LLVM_DRIVER_BUILD combines many llvm executables into one to save overall toolchain size. This patch adds a few more llvm tools to the llvm-driver. Differential Revision: https://reviews.llvm.org/D135281
2022-08-30[llvm-size] Fix missing file name for darwin output format with non-Mach-OShivam Gupta1-0/+4
llvm-size falls back to printing in Berkeley format, if --format=darwin is specified and a non-Mach-O object has been provided. However, it does not print the input filename when it should: Before - (base) xgupta@archlinux ~/llvm/llvm-project/build (main*) $ llvm-size ~/hello.o --format=darwin text data bss dec hex filename 291 0 0 291 123 % After - (base) xgupta@archlinux ~/llvm/llvm-project/build (main*) $ bin/llvm-size ~/hello.o --format=darwin text data bss dec hex filename 291 0 0 291 123 /home/xgupta/hello.o Fix #42316 Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D132364
2022-07-18[llvm-size] Fix hang waiting for input on invalid short commandline optiongbreynoo1-2/+5
When an invalid shot command line option was used (e.g. -v) llvm-size would hang waiting on input from stdin. This change fixes this issue by bringing llvm-size in line with other llvm tools and exiting early when this error is output. Differential Revision: https://reviews.llvm.org/D129866
2021-07-09[llvm-size] Switch command line parsing from llvm::cl to OptTableFangrui Song3-80/+148
Part of https://lists.llvm.org/pipermail/llvm-dev/2021-July/151622.html "Binary utilities: switch command line parsing from llvm::cl to OptTable" * `--totals=false` and `--totals=0` cannot be used. Omit the option. * `--help-list` is removed. This is a `cl::` specific option. OptTable avoids global option collision if we decide to support multiplexing for binary utilities. Note: because the tool is simple, and its long options are uncommon, I just drop the one-dash forms except `-arch <value>` (Darwin style). Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D105598
2020-12-27[llvm-cov] Use is_contained (NFC)Kazu Hirata1-3/+1
2020-11-13llvmbuildectomy - replace llvm-build by plain cmakeserge-sans-paille1-21/+0
No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-07-01[llvm-size] Output REL, RELA and STRTAB sections when allocatablegbreynoo1-1/+2
gnu size has a number of special cases regarding REL, RELA and STRTAB sections being considered in size output. To avoid unnecessary complexity this commit makes llvm size outputs these sections in cases they have the SHF_ALLOC flag. Differential Revision: https://reviews.llvm.org/D82479
2020-05-06[llvm-nm/objdump/size] Add tests for dumping symbol tables with invalid sh_size.Xing GUO1-1/+0
This change adds tests for llvm-nm, llvm-objdump and llvm-size when dumping symbol tables with invalid sh_size (sh_size % sizeof(Elf_Sym) != 0). Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D77864
2020-04-18[Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> ↵vgxbj1-9/+25
getSymbolFlags(). This change enables getSymbolFlags() to return errors which benefit error reporting in clients. Differential Revision: https://reviews.llvm.org/D77860
2020-01-03[llvm-size] print a blank line between archieve members when using sysv formatTH3CHARLie1-4/+2
Summary: This patch is related to https://bugs.llvm.org/show_bug.cgi?id=42967 and it fixes llvm-size's sysv format output by adding a blank line between archieve members Reviewers: jhenderson, Jim, MaskRay Reviewed By: jhenderson, Jim, MaskRay Subscribers: MaskRay, Jim, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71957
2019-10-14Reapply: [llvm-size] Tidy up error messages (PR42970)Jordan Rupprecht1-22/+22
Clean up some formatting inconsistencies in the error messages and correctly exit with non-zero in all error cases. Originally submitted as r374771 and then reverted as r374780, this patch fixes the libObject test case in Object/macho-invalid.test. Patch by Alex Cameron Differential Revision: https://reviews.llvm.org/D68906 llvm-svn: 374793
2019-10-14Revert r374771 "[llvm-size] Tidy up error messages (PR42970)"Nico Weber1-22/+22
This reverts commit 83e52f5e1150018329b8907bb014c77ac382d611. Makes Object/macho-invalid.test fail everywhere, e.g. here: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/23669/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3Amacho-invalid.test llvm-svn: 374780
2019-10-14[llvm-size] Tidy up error messages (PR42970)Fangrui Song1-22/+22
Clean up some formatting inconsistencies in the error messages and correctly exit with non-zero in all error cases. Differential Revision: https://reviews.llvm.org/D68906 Patch by Alex Cameron llvm-svn: 374771
2019-09-13[llvm-size] Fix spelling errors (Berkely -> Berkeley)James Henderson1-3/+3
llvm-svn: 371845
2019-08-14Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar1-19/+13
Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
2019-08-14Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar1-13/+19
Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
2019-08-14[llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar1-19/+13
SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
2019-06-21[binutils] Add response file option to help and docsJames Henderson1-0/+3
Many LLVM-based tools already support response files (i.e. files containing a list of options, specified with '@'). This change simply updates the documentation and help text for some of these tools to include it. I haven't attempted to fix all tools, just a selection that I am interested in. I've taken the opportunity to add some tests for --help behaviour, where they were missing. We could expand these tests, but I don't think that's within scope of this patch. This fixes https://bugs.llvm.org/show_bug.cgi?id=42233 and https://bugs.llvm.org/show_bug.cgi?id=42236. Reviewed by: grimar, MaskRay, jkorous Differential Revision: https://reviews.llvm.org/D63597 llvm-svn: 364036
2019-06-05Sanitize llvm-size helpSerge Guelton1-26/+32
Remove irrelevant options from standard help output. New output: OVERVIEW: llvm object size dumper USAGE: llvm-size [options] <input files> OPTIONS: Generic Options: --help - Display available options (--help-hidden for more) --help-list - Display list of available options (--help-list-hidden for more) --version - Display the version of this program llvm-size Options: Specify output format -A - System V format -B - Berkeley format -m - Darwin -m format --arch=<string> - architecture(s) from a Mach-O file to dump --common - Print common symbols in the ELF file. When using Berkely format, this is added to bss. Print size in radix: -o - Print size in octal -d - Print size in decimal -x - Print size in hexadecimal --format=<value> - Specify output format =sysv - System V format =berkeley - Berkeley format =darwin - Darwin -m format -l - When format is darwin, use long format to include addresses and offsets. --radix=<value> - Print size in radix =8 - Print size in octal =10 - Print size in decimal =16 - Print size in hexadecimal --totals - Print totals of all objects - Berkeley format only Differential Revision: https://reviews.llvm.org/D62482 llvm-svn: 362593
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2-8/+6
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-12-20[binutils] NFC: fix clang-tidy warning: use empty() instead of size() == 0Jordan Rupprecht1-1/+1
llvm-svn: 349710
2018-12-13[llvm-size][libobject] Add explicit "inTextSegment" methods similar to ↵Jordan Rupprecht1-2/+2
"isText" section methods to calculate size correctly. Summary: llvm-size uses "isText()" etc. which seem to indicate whether the section contains code-like things, not whether or not it will actually go in the text segment when in a fully linked executable. The unit test added (elf-sizes.test) shows some types of sections that cause discrepencies versus the GNU size tool. llvm-size is not correctly reporting sizes of things mapping to text/data segments, at least for ELF files. This fixes pr38723. Reviewers: echristo, Bigcheese, MaskRay Reviewed By: MaskRay Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54369 llvm-svn: 349074
2018-11-22[llvm-size] Use empty() and range-based for loop. NFCFangrui Song1-5/+5
llvm-svn: 347441
2018-11-11[Support] Make error banner optional in logAllUnhandledErrorsJonas Devlieghere1-2/+2
In a lot of places an empty string was passed as the ErrorBanner to logAllUnhandledErrors. This patch makes that argument optional to simplify the call sites. llvm-svn: 346604
2018-10-30[llvm-size] Reject unknown radix valuesJames Henderson1-4/+6
This addresses https://bugs.llvm.org/show_bug.cgi?id=39403 by making -radix an enumeration option with 8, 10, and 16 as the only accepted values. Reviewed by: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D53799 Patch by Eugene Sharygin llvm-svn: 345588
2018-09-21[llvm-size] Berkeley formatting: use tabs instead of spaces as field delimeters.Jordan Rupprecht1-12/+18
This matches GNU behavior for size and allows use of cut to parse the output of llvm-size. llvm-svn: 342791
2018-06-22[llvm-size] Make global variables staticFangrui Song1-2/+2
llvm-svn: 335397
2018-04-13Define InitLLVM to do common initialization all at once.Rui Ueyama1-8/+2
We have a few functions that virtually all command wants to run on process startup/shutdown. This patch adds InitLLVM class to do that all at once, so that we don't need to copy-n-paste boilerplate code to each llvm command's main() function. Differential Revision: https://reviews.llvm.org/D45602 llvm-svn: 330046
2017-12-18Fix more inconsistent line endings. NFC.Dimitry Andric1-7/+7
llvm-svn: 321016
2017-11-03Add llvm::for_each as a range-based extensions to <algorithm> and make use ↵Aaron Ballman1-8/+7
of it in some cases where it is a more clear alternative to std::for_each. llvm-svn: 317356
2017-11-02[tools] Add option to install binutils symlinksShoaib Meenai1-0/+4
The LLVM tools can be used as a replacement for binutils, in which case it's convenient to create symlinks with the binutils names. Add support for these symlinks in the build system. As with any other llvm tool symlinks, the user can limit the installed symlinks by only adding the desired ones to `LLVM_TOOLCHAIN_TOOLS`. Differential Revision: https://reviews.llvm.org/D39530 llvm-svn: 317272
2016-12-23llvm-size: remove leading dash in '-radix' optionMehdi Amini1-1/+1
cl::opt does not accept such option llvm-svn: 290466
2016-12-16Fix a bugs with using some Mach-O command line flags like "-arch armv7m".Kevin Enderby1-20/+20
The Mach-O command line flag like "-arch armv7m" does not match the arch name part of its llvm Triple which is "thumbv7m-apple-darwin”. I think the best way to fix this is to have llvm::object::MachOObjectFile::getArchTriple() optionally return the name of the Mach-O arch flag that would be used with -arch that matches the CPUType and CPUSubType. Then change llvm::object::MachOUniversalBinary::ObjectForArch::getArchTypeName() to use that and change it to getArchFlagName() as the type name is really part of the Triple and the -arch flag name is a Mach-O thing for a specific Triple with a specific Mcpu value. rdar://29663637 llvm-svn: 290001
generated by cgit v1.1 at 2025-09-29 13:25:27 +0000