aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-03-06Handle DW_TAG_module for AdaTom Tromey1-8/+19
This updates read_module_type to turn DW_TAG_module into a TYPE_CODE_NAMESPACE when the CU represents Ada code. Note that the GNAT that generates this isn't generally available yet and so this shouldn't have an impact on current code.
2025-03-06Add "synthetic" marker for index entriesTom Tromey3-9/+11
Currently, gdb will synthesize DW_TAG_module entries for Ada names. These entries are treated specially by the index writer, When GNAT starts emitting DW_TAG_module, the special case will be incorrect, because there will be non-synthetic DW_TAG_module entries in the index. This patch arranges to mark the synthetic entries and changes the index writer to follow.
2025-03-06Use DW_TAG_module for AdaTom Tromey3-3/+6
In GCC we decided to use DW_TAG_module to represent Ada packages, so make this same decision in gdb. This also updates tag_matches_domain to handle this case.
2025-03-06Use dwarf2_full_name when computing type namesTom Tromey1-4/+5
This changes a few spots in the DWARF reader to use dwarf2_full_name when computing the name of a type. This gives the correct name when a type is nested in a namespace. This oddity probably wasn't noticed before because some of the types in question are either normally anonymous in C++ (e.g, array type) or do not appear in a namespace (base type).
2025-03-06Compare unqualified names in ada_identical_enum_types_pTom Tromey1-11/+21
With the coming changes to GNAT, gdb must compare the unqualified names of two enum types. Currently, GNAT will fully-qualify enumeration constant names, so for instance one might see "enum_with_gap__lit4" as the name. GNAT also may emit a copy of an enumeration type when a newtype is involved. E.g., in the arr_acc_idx_w_gap.exp test case, this can occur for the base type of this subtype: type Enum_Subrange is new Enum_With_Gaps range Lit1 .. Lit3; (Note that the base type of this subrange is anonymous.) With some forthcoming changes to GNAT, these names will no longer be qualified -- and because the newtype is anonymous, they can't be identically qualified. But, in gdb we still want "lit4" to resolve without ambiguity in this scenario. The fix is to change ada_identical_enum_types_p to compare unqualified enum names. This will work correctly with both variants of the compiler, and with -fgnat-encodings=all as well.
2025-03-06Use ada_identical_enum_types_p in ada_atr_enum_repTom Tromey1-1/+8
With the coming changes to GNAT, we may see two distinct but equivalent enum types in the DWARF. In this case, it's better to use ada_identical_enum_types_p rather than types_equal when comparing these types... something that matters when using 'Enum_Rep.
2025-03-06Fixes to gdb.ada/fun_overload_menu.expTom Tromey2-19/+28
This patch applies a few fixes to gdb.ada/fun_overload_menu.exp. It adds some comments to the source and uses this to extract line numbers. This is used to ensure that two otherwise-equivalent results are in fact different, so that the test really checks that the result is correct. It also changes the test_menu proc to accept a list of possible results. This lets the test work regardless of the order in which the menu items are presented by gdb. Finally, like an earlier patch, it changes the test to optionally accept unqualified names from gdb.
2025-03-06Allow multiple locations in homonym.expTom Tromey1-1/+1
With some forthcoming changes to GNAT, the two Get_Value functions in this test case will end up with the same name (with the current GNAT, one ends up with a "__2" suffix). This change will cause one test to set multiple breakpoints; this patch changes the test to work with either version of the compiler.
2025-03-06Fix type name in ptype-o.expTom Tromey3-10/+28
The "Rec" type in ptype-o.exp is currently named "prog__rec" by the compiler. However, with my changes to GNAT, the type will no longer have a prefix, as it is local to a procedure. Changing this to just use "rec" works fine with the new compiler, but then fails with older compilers. To allow correct operation with both compilers, this patch simply moves the type into a new package. This doesn't affect the meaning of the test, which is just ensuring that ptype/o works in a certain case. Note that the more obvious fix of just using "ptype/o rec" does not work with the current GNAT. I haven't investigated this but I did file a bug to track it: https://sourceware.org/bugzilla/show_bug.cgi?id=32169
2025-03-06Allow unqualified names in Ada testsTom Tromey14-28/+47
Currently, when a type is declared in a subprogram that isn't part of a package, gdb will give this type a qualified name. E.g., in the program for gdb.ada/arr_arr.exp: procedure Foo is type Array2_First is array (24 .. 26) of Integer; gdb will name this type 'foo.array2_first'. However, with some coming changes to GNAT (and with the remainder of this series applied as well), this will no longer happen. Instead, such types will be given their local name. IMO this makes more sense anyway. This patch updates most of the Ada tests to allow either form in the spots where it matters. Both are accepted so that the tests continue to work with older versions of GNAT. (A few tests are handled in separate patches; this patch only contains the straightforward changes.)
2025-03-06Fix latent crash in ada_variant_discrim_nameTom Tromey1-2/+4
ada_variant_discrim_name does this: for (discrim_end = name + strlen (name) - 6; discrim_end != name; If NAME is too short, this will construct an invalid pointer, perhaps causing a crash. This patch arranges to check the length first.
2025-03-06Allow for anonymous Ada enumeration typesTom Tromey1-1/+4
With some forthcoming changes to GNAT, gdb might see a nameless enum in ada_resolve_enum, causing a crash. This patch allows an anonymous enum type to be considered identical to a named type when the contents are identical.
2025-03-06Add a quit to maint_print_all_sectionsTom Tromey1-0/+3
If you have many sections, "maint print sections" can take a very long time (due to a bug). If you happen to "c" at the pagination prompt, this can't be interrupted. This patch adds a QUIT to the loop to at least allow interruption. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758 Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2025-03-06[gdbserver] Drop abbreviations in gdbserver/xtensa-xtregs.ccTom de Vries1-2/+18
In gdbserver/xtensa-xtregs.cc, there's a table: ... const xtensa_regtable_t xtensa_regmap_table[] = { /* gnum,gofs,cpofs,ofs,siz,cp, dbnum, name */ { 44, 176, 0, 0, 4, -1, 0x020c, "scompare1" }, { 0 } }; ... on which codespell triggers: ... $ codespell --config ./gdbserver/setup.cfg gdbserver gdbserver/xtensa-xtregs.cc:34: siz ==> size, six ... Fix this by laying out the table in vertical fashion, and using the full field names instead of the abbreviations ("size" instead of "siz", "offset" instead of "ofs", etc). Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-06Use 'const' in some gdbarch methodsTom Tromey9-20/+24
This changes a couple of gdbarch methods to use 'const' for an "asymbol *" parameter. These methods shouldn't be modifying the underlying symbol in the BFD. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-06[gdbserver] Add codespell section in setup.cfgTom de Vries1-0/+4
Add a codespell section in new config file gdbserver/setup.cfg, similar to the one in gdbsupport/setup.cfg. There's just one item left: ... $ codespell --config ./gdbserver/setup.cfg gdbserver gdbserver/xtensa-xtregs.cc:34: siz ==> size, six ...
2025-03-06gdb/dwarf: remove unnecessary `this->` in read.cSimon Marchi1-45/+44
I like using `this->` when it's unclear that the method or field accessed is within the current class, but when accessing a private member prefixed with `m_`, it's unnecessary, as the prefix makes it clear. Remove some instances of it (some coming from the previous patch, other pre-existing) to de-clutter the code a bit. Change-Id: Ia83d0bce51d222fa3ac3d756d50170ec6ed12b94 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06gdb/dwarf: make all fields of cutu_reader privateSimon Marchi1-272/+279
Make all fields of cutu_reader private, then add getters for whatever needs to be accessed outside of cutu_reader. This should help spot what's used by cutu_reader itself, and what is used by others. Change-Id: I71cb73fffa5d70cc9c7fc68bf74db937e84c2db1 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06gdb/dwarf: pass dwarf2_cu instead of cutu_reader to two functionsSimon Marchi1-7/+4
These functions don't need to receive a cutu_reader, they only use it to obtain the contained dwarf2_cu, so change them to accept a dwarf2_cu. This helps reduce the creep of cutu_reader a little bit. Change-Id: Iebb3c4697a4aec638b47423b3ac59077d4fa5090 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06gdb/dwarf: move a bunch of DIE-reading functions to cutu_readerSimon Marchi1-153/+154
With the hope of organizing things better and spotting patterns that could lead to simplification, move all these functions to be methods of cutu_reader. At least, this gives a good picture of what the entry points for DIE and attribute reading are, by looking at what methods are public. Right now, my vague understanding of cutu_reader is that it does 3 things: - it provides means to navigate and read the DIE tree, abstracting things like whether the real content is in a DWO file or not - it builds a dwarf2_cu object, for its own use but also for the use of the caller - it fills in missing details in the passed in dwarf2_per_cu In the future, I'd like to separate those concerns. I think that cutu_reader could retain the first one of those concerns, while the other two could be done by other classes or functions, perhaps using cutu_reader under the hood. Change-Id: I04e0d6c864bbc09c7071ac8e9493e1e54c093d68 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06gdb/dwarf: add empty lines in cutu_reader::read_cutu_die_from_dwo commentSimon Marchi1-0/+3
I find it much more readable this way, with one idea per paragraph. Change-Id: Ib31b410867c8444e0f3200681881f54f1b8ebea8 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06gdb/dwarf: make init_cu_die_reader a method of cutu_readerSimon Marchi1-16/+20
init_cu_die_reader is only used inside cutu_reader, to initialize fields of cutu_reader, so make it a private method. Change-Id: Iaa80d4dbb8d0fa35bcac18ee70e147276874cc1b Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06gdb/dwarf: make read_cutu_die_from_dwo a method of cutu_readerSimon Marchi1-20/+25
read_cutu_die_from_dwo is only used as a helper to cutu_reader, so make it a private method of cutu_reader. Remove the "result_reader" parameter, because it's always "this". Change-Id: I7df6162137451c160f0e6bf3539569fcb2421eff Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06[gdbsupport] Add codespell section in setup.cfgTom de Vries2-0/+7
When running codespell on gdbsupport, we get: ... $ codespell gdbsupport gdbsupport/common-debug.h:218: invokable ==> invocable gdbsupport/osabi.h:51: configury ==> configurable gdbsupport/ChangeLog-2020-2021:344: ro ==> to, row, rob, rod, roe, rot gdbsupport/ChangeLog-2020-2021:356: contaning ==> containing gdbsupport/common.m4:19: configury ==> configurable gdbsupport/Makefile.am:97: configury ==> configurable gdbsupport/Makefile.in:811: configury ==> configurable gdbsupport/event-loop.cc:84: useable ==> usable gdbsupport/configure:15904: assigment ==> assignment ... Some of these files we want to skip in a spell check, because they're generated. We also want to skip ChangeLogs, we don't actively maintain those. Add a file gdbsupport/setup.cfg with a codespell section, that skips those files. The choice for setup.cfg (rather than say .codespellrc) comes from the presence of gdb/setup.cfg. That leaves invokable, configury and useable. I think configury is a common expression in our context, and for invokable and useable I don't manage to find out whether they really need rewriting, so I'd rather leave them alone for now. Add these to a file gdb/contrib/codespell-ignore-words.txt, and use the file in gdbsupport/setup.cfg. This makes the directory codespell clean: ... $ codespell --config gdbsupport/setup.cfg gdbsupport $ ... Because codespell seems to interpret filenames relative to the working directory rather than relative to the config file, and the filename used in gdbsupport/setup.cfg is gdb/contrib/codespell-ignore-words.txt, this simple invocation doesn't work: ... $ cd gdbsupport $ codespell ... because codespell can't find gdbsupport/gdb/contrib/codespell-ignore-words.txt. We could fix this by using ../gdb/contrib/codespell-ignore-words.txt instead, but likewise that breaks this invocation: ... $ codespell --config gdbsupport/setup.cfg gdbsupport ... I can't decide which one is worse, so I'm sticking with gdb/contrib/codespell-ignore-words.txt for now. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-06gdb: remove unnecessary local variable in pager_file::putsSimon Marchi1-18/+15
The lineptr variable isn't really necessary, we can just keep using linebuffer, since the original value is linebuffer isn't needed. Remove lineptr, and fix some comparisons to be explicit. Change-Id: If2f7df43bf79efd40149e46d5c77f9bc0439f879 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-06[gdbserver] Fix some typosTom de Vries8-13/+13
Fix typos in gdbserver: ... gdbreplay.cc:444: substract ==> subtract notif.cc:35: Enque ==> Enqueue notif.cc:42: enque ==> enqueue i387-fp.cc:233: simplifed ==> simplified i387-fp.cc:508: simplifed ==> simplified linux-arc-low.cc:221: shoudn't ==> shouldn't linux-sparc-low.cc:112: ans ==> and linux-ppc-low.cc:1134: Followings ==> Following linux-ppc-low.cc:1160: Followings ==> Following linux-ppc-low.cc:1193: Followings ==> Following linux-ppc-low.cc:1226: Followings ==> Following configure.ac:141: defintions ==> definitions ... Regenerate configure from configure.ac using autoconf.
2025-03-06Use "::" as separator for Fortran in cooked indexTom Tromey1-0/+1
This teaches cooked_index_entry::full_name that "::" is the separator for Fortran. I don't know enough Fortran to write a test case for this. However, a different series I am working on has a regression if this patch is not applied. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-06Avoid double-decoding in ada_add_global_exceptionsTom Tromey1-11/+9
I noticed that ada_add_global_exceptions calls ada_decode on 'search_name' -- and then passes this to name_matches_regex, which also calls ada_decode. name_matches_regex is also used later, where the result of 'natural_name ()' is passed to it -- but natural_name also calls ada_decode. So, I think the call to ada_decode in name_matches_regex is redundant. This patch removes it, and turns name_matches_regex into an inner function to avoid propagating its use. Note that, right now, the DWARF implementation of expand_symtabs_matching does not in fact pass an encoded name to this callback. So, this code remains slightly (but currently harmlessly) wrong. expand_symtabs_matching is fixed by another pending series of mine.
2025-03-06[gdbsupport] Fix some typosTom de Vries3-4/+4
Fix typos: ... mentionning -> mentioning suppported -> supported aligment -> alignment ...
2025-03-06[gdb] Fix typos in some selftestsTom de Vries3-5/+5
Fix typos: ... figured on out -> figured one out fpr -> for hopefuly -> hopefully ...
2025-03-06Revert "gprof: only process line numbers for intersection of vmas and ↵H.J. Lu2-63/+56
histograms" This reverts commit b8189cf9e40bd90502c9a2ce0df39dd54419bea4 to fix PR gprof/32764: https://sourceware.org/bugzilla/show_bug.cgi?id=32764
2025-03-06Automatic date update in version.inGDB Administrator1-1/+1
2025-03-06ld: Update PR ld/25237 testH.J. Lu2-4/+7
1. Skip targets which don't support the .bss section alignment, 1 << 16. 2. Replace .bss with ".section .bss". 3. Use ".zero 0xb60000" for targets which pad the section to its alignment. PR ld/25237 * testsuite/ld-elf/pr25237.d: Skip avr-*-* and h8300-*-*. Update expected segment size to 0xb60000. * testsuite/ld-elf/pr25237.s: Use ".section .bss" and ".zero 0xb60000". Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-03-05gdb/testsuite: add test for memory requirements of gcoreGuinevere Larsen2-0/+149
For a long time, Fedora has been carrying an out-of-tree patch with a similar test to the one proposed in this patch, that ensures that the memory requirements don't grow with the inferior's memory. It's been so long that the context for why this test exists has been lost, but it looked like it could be interesting for upstream. The test runs twice, once with the inferior allocating 4Mb of memory, and the other allocating 64Mb. My plan was to find the rate at which things increase based on inferior size, and have that tested to ensure we're not growing that requirement accidentally, but my testing actually showed memory requirements going down as the inferior increases, so instead I just hardcoded that we need less than 2Mb for the command, and it can be tweaked later if necessary. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb: do not handle a NULL linebuffer in pager_file::putsSimon Marchi1-2/+1
This patch [1] has shown that different implementations of ui_file::puts handle a NULL line differently. pager_file::puts handles a NULL argument gracefully, as a no-op, while other implementations don't and likely crash. This causes subtle bugs: things will be working until the current ui_file is suddenly not a pager_file anymore. I think it would be better to be consistent here, so change pager_file::puts to not accept a NULL line. A regular test run on Linux shows no regression. [1] https://inbox.sourceware.org/gdb-patches/edfe6e17-1c20-4a4c-944f-247ff71b6c10@simark.ca/T/#m864aea10de8ca6fa84757971fcbaf3180e2eaefa Change-Id: Ieb465c86cd2c42a248cf481cd174c8622ef6724b Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05Inconsistent treatment of template parameters in DWARF readerTom Tromey2-14/+7
I noticed that if you hack some clean_restart calls into paramless.exp, the test will fail. That is, the test currently relies on the desired CUs already being expanded when trying to set a breakpoint -- which is clearly a bug, the CU expansion state should not affect "break". I tracked this down to incorrect construction of a lookup_name_info in cooked_index_functions::expand_symtabs_matching. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32510 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-05gdb/dwarf: store dwo_file_up in dwo_file_setSimon Marchi2-92/+97
Heap-allocated dwo_file objects, stored in dwarf2_per_bfd::dwo_files, are never freed. They are created in one of the create_dwo_unit_in_dwp_* or lookup_dwo_cutu functions. I confirmed this by running: $ make check TESTS="gdb.cp/anon-ns.exp" RUNTESTFLAGS="--target_board=fission-dwp" $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.cp/anon-ns/anon-ns -ex "p main" -ex "file" -batch ... and checking the ASan leak report. I also debugged this invocation of GDB, placed a breakpoint on ~dwo_file, and didn't see any hit. Change the dwo_file set to hold dwo_file_up objects. When the dwarf2_per_bfd object gets destroyed, dwo_file objects will automatically get destroyed. With this change, I see the related leaks disappear in the ASan leak report, and my ~dwo_file breakpoint gets hit when debugging GDB. Change-Id: Icb38539c3f9e553f3625c625a00fc63dd6e9f3c5 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb/dwarf: make dwarf2_per_bfd::dwo_files a gdb::unordered_setSimon Marchi2-166/+147
Change the dwarf2_per_bfd::dwo_files htab to a gdb::unordered_set. No behavior change expected, except maybe the failure case in lookup_dwo_cutu. If open_and_init_dwo_file returns nullptr, the previous code would leave the slot value empty (nullptr). Is this legit? With the new hash table, the only thing we can do really is not attempt to insert the nullptr value. Change-Id: I63992f388b1197e696ded4ea483634e8ae67fce4 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb/dwarf: change htabs holding dwo_unit objects to gdb::unordered_setSimon Marchi1-181/+99
Change a few occurences of htabs holding `dwo_unit *` values, using their signature as identity, to gdb::unordered_set. allocate_dwo_unit_table and allocate_dwp_loaded_cutus_table appeared to create hash tables with identical behavior, so they both use the same set type now. The only expected change in behavior is that when there are multiple units with the same signature, we will now keep the unit previously in the set, rather than overwriting it. But this seems ok, as it's a case of bad DWARF. Also, in the complaint in create_debug_type_hash_table, I think we previously erroneously printed the same sect_off twice. Change-Id: I57739977735ee1fd5c7b754107f5624f0621baa5 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb/dwarf: remove unused local variable in create_debug_type_hash_tableSimon Marchi1-1/+0
Change-Id: I40679fbe32a8a1a9cced085532c83f06affc294c Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb/dwarf: remove unnecessary parameters to create_{cus,debug_type}_hash_tableSimon Marchi1-30/+21
In create_cus_hash_table, we can get the section and hash table from the dwo_file directly. In create_debug_type_hash_table, we can get the hash table from the dwo_file directly - the section varies. Change-Id: I1d5ef49df98fe2620e12b83484b28cd7398f24ae Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb/dwarf: remove die_reader_specsSimon Marchi1-109/+78
die_reader_specs is a relic of some past design, today it only serves as (useless) a base class for cutu_reader. Remove it and move all its fields to cutu_reader. Change-Id: I5d55018eb8c6e0b828ef5d2f6d09b2047d1a5912 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb/dwarf: remove unnecessary parameter of create_cus_hash_tableSimon Marchi1-4/+3
We can use `cu->per_objfile` instead of passing down a dwarf2_per_objfile explicitly. Change-Id: Ie1fd93d9e7a74d09b857f1f0909d7441b79ed893 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb/dwarf: remove unnecessary local variable in dw2_get_file_names_readerSimon Marchi1-3/+2
It seems like the lh_cu variable is not necessary, we can just use this_cu. Change-Id: Ic2ed6ee82faf1fb5d340cd92dc8ef15434b20cb8 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-05gdb: fix null pointer dereference on missing PATH variableDaniel Starke1-3/+4
When running "show" with missing PATH variable a null pointer is being dereferenced in path_info(). path_command() correctly checks whether PATH has been set before using it. It then calls path_info() which retrieves the variable again but fails to perform the null pointer test on it. As a result, the application crashes with SIGSEGV on Windows for example. Fix this by handling the null pointer case in path_info() accordingly. Signed-off-by: Daniel Starke <daniel-email@gmx.net> Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com> Change-Id: I41ef10f00802d3163793491454190008e78f5dc1
2025-03-05Create dwarf2/parent-map.cTom Tromey3-66/+89
This creates a new file, dwarf2/parent-map.c, to hold some code related to parent maps. This helps shrink read.c a bit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-05Dump debug names indexTom Tromey1-1/+1
This changes the .debug_names reader to dump the contents of the index. This follows what the cooked index does, and also fixes a couple of test failures when run with the debug-names board: forward-spec-inter-cu.exp and backward-spec-inter-cu.exp. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-05elfxx-aarch64.c: Replace nested function with a static inline version instead.Nick Clifton1-10/+13
2025-03-05ld: Add a test for PR ld/25237H.J. Lu2-0/+25
PR ld/25237 * testsuite/ld-elf/pr25237.d: New file. * testsuite/ld-elf/pr25237.s: Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-03-05ld: Pass -Wl,-z,lazy to compiler for i386 lazy binding testsH.J. Lu2-8/+8
Pass -Wl,-z,lazy to compiler for i386 tests which require lazy binding to support compilers which default to non-lazy binding. PR ld/32762 * testsuite/ld-i386/i386.exp: Pass -Wl,-z,lazy for "Build ifunc-1a with PIE -z ibtplt" test. * testsuite/ld-i386/no-plt.exp: Pass -Wl,-z,lazy for "Build libno-plt-1b.so", "No PLT (dynamic 1a)", "No PLT (dynamic 1b)", "No PLT (dynamic 1c)", "No PLT (PIE 1e)", "No PLT (PIE 1f)", "No PLT (PIE 1g)" tests. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>