aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-23gas: make .nops output visible in listingJan Beulich5-2/+71
Due to using a different frag type (in turn due to storing data differently), making the resulting code appear in listings requires special handling.
2023-10-23x86: fold NOP testcase expectations where possibleJan Beulich14-2340/+14
Like done earlier for files needing adjustment anyway, also do this for the remaining set.
2023-10-23x86: fold a few of the "alternative" NOP patternsJan Beulich1-6/+3
Since named objects may not overlap, the compiler is not permitted to do this for us, to avoid wasting space and cache bandwidth/capacity.
2023-10-23x86: add a few more NOP patternsJan Beulich32-2270/+465
First of all add f32_5[], allowing to eliminate the extra slot-is-NULL code from i386_output_nops(). Plus then introduce f32_8[] and f16_5[] following the same concept of adding a %cs segment override prefix. Also re-use patterns when possible and correct comments as applicable. Similarly re-use testcase expectations as much as possible, where they need touching anyway.
2023-10-23x86: don't record full i386_cpu_flags in struct i386_tc_frag_dataJan Beulich2-4/+4
We only use a single bit of this ever growing structure.
2023-10-23x86: i686 != PentiumProJan Beulich2-3/+6
The two are distinct in opcodes/, distinguished precisely by CpuNOP that's relevant in i386_generate_nops(), yet the function has the PPro case label in the other group. Simply removing it revealed that cpu_arch[] had a wrong entry for i686. While there also add PROCESSOR_IAMCU to the respective comment.
2023-10-23x86: respect ".arch nonop" when selecting which NOPs to emitJan Beulich5-27/+23
Making GENERIC64 a special case was never correct; prior to the generalization of ".arch .no*" to cover all ISA extensions other processor families supporting long NOPs should have been covered as well. When introducing ".arch .nonops" (among others) it wasn't apparent that a hidden implication of .cpunop not being possible to separately turn off existed here. Seeing that the two large case label blocks in the 2nd switch() already had identical behavior, simply collapse all of the (useful) case labels into a single "default" one.
2023-10-23x86: don't use operand size override with NOP in 16-bit codeJan Beulich4-11/+12
Since we don't key the NOP selection to user-controlled properties, we may not use i386 features; otherwise we would violate a possible .arch directive restricting ISA to pre-386.
2023-10-23x86: don't use 32-bit LEA as NOP surrogate in 64-bit codeJan Beulich3-197/+41
Except for the shared 1- and 2-byte cases, the LEA uses corrupt %rsi (by zero-extending %esi to %rsi). Introduce separate 64-bit patterns which keep %rsi intact.
2023-10-23x86: i386_generate_nops() may not derive decisions from global variablesJan Beulich7-2/+43
What matters is what was in effect at the time the original directive was issued. Later changes to global state (bitness or ISA) must not affect what code is generated.
2023-10-23x86: record flag_code in tc_frag_dataJan Beulich2-14/+16
The recorded value, and not the global variable, will want using in TC_FRAG_INIT(). The so far file scope variable therefore needs to become external, to be accessible there.
2023-10-23objcopy: fix typo in --heap and --stack parserClément Chigot2-4/+4
The help says that <reserve> and <commit> should be separated by a "," but the implementation is checking for ".". Having two numbers being separated by a "." could be confusing, thus adjust the implementation to match the help syntax. binutils/ChangeLog: * objcopy.c (copy_main): Set separator to "," between <reserve> and <commit> for --heap and --stack. * doc/binutils.texi: Add <commit> for --heap and --stack.
2023-10-23Automatic date update in version.inGDB Administrator1-1/+1
2023-10-23bfd-in2.h BFD_RELOC_* commentsAlan Modra5-1647/+1576
I noticed the regenerated BFD_RELOC_MICROBLAZE_32_NONE comment didn't match that committed to bfd-in2.h, and was just going to regen bfd-in2.h but then decided to do something about the silly formatting of these comments in bfd-in2.h. eg. the BFD_RELOC_MICROBLAZE_32_NONE comment: -/* This is a 32 bit reloc that stores the 32 bit pc relative -value in two words (with an imm instruction).No relocation is -done here - only used for relaxing */ + /* This is a 32 bit reloc that stores the 32 bit pc relative value in + two words (with an imm instruction). No relocation is done here - + only used for relaxing. */ BFD_RELOC_MICROBLAZE_32_NONE, You'll notice how the second and third line of the original comment aren't indented properly relative to the first line, and the whole comment needs to be indented to match the code. I've also edited reloc.c ENUMDOC paragraphs. Some of these had excess indentation, presumably in an attempt to properly indent bfd-in2.h comments but that fails due to chew.c removing leading whitespace early by skip_white_and_stars. COMMENT was used in reloc.c to add extra blank lines in bfd-in2.h. I've removed them too as I don't think they add anything to readability of that file. (Perhaps more usefully, they also add blank lines to libbfd.h separating relocs for one target from others, but this isn't done consistently.) * doc/chew.c (drop, idrop): Move earlier. (strip_trailing_newlines): Check index before accessing array, not after. (wrap_comment): New function. (main): Add "wrap_comment" intrinsic. * doc/proto.str (ENUMDOC): Use wrap_comment. (make_enum_header, ENDSENUM): Put start and end braces on separate lines. * reloc.c: Remove uses of COMMENT and edit ENUMDOC paragraphs. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2023-10-22Style history variable outputTom Tromey2-2/+5
When printing a value, I think the history reference -- the "$1" in the output -- should be styled using the "variable" style. This patch implements this.
2023-10-22Automatic date update in version.inGDB Administrator1-1/+1
2023-10-20gdb: fix owner passed to remove_target_sections in clear_solibSimon Marchi6-18/+51
Commit 8971d2788e7 ("gdb: link so_list using intrusive_list") introduced a bug in clear_solib. Instead of passing an `so_list *` to remove_target_sections, it passed an `so_list **`. This was not caught by the compiler, because remove_target_sections takes a `void *` as the "owner", so you can pass it any pointer and it won't complain. This happened because I previously had a patch to change the type of the disposer parameter to be a reference rather than a pointer, so had to change `so` to `&so`. When dropping that patch, I forgot to revert this bit and / or it got re-introduced when handling subsequent merge conflicts. And I didn't properly retest. Fix that, but try to make things less error prone. Add a union to represent the possible owner kinds for a target_section. Trying to pass a pointer to another type than those will not compile. Change-Id: I600cab5ea0408ccc5638467b760768161ca3036c
2023-10-21Automatic date update in version.inGDB Administrator1-1/+1
2023-10-20[gdb/cli] Allow source-highlight to autodetect languageTom de Vries1-2/+16
Currently when gdb asks the source-highlight library to highlight a file, it tells it what language file to use. For instance, if gdb learns from the debug info that the file is language_c, the language file "c.lang" is used. This mapping is hardcoded in get_language_name. However, if gdb doesn't know what language file to use, it falls back to using python pygments, and in absence of that, unhighlighted source text. In the case of python pygments, it autodetects which language to use based on the file name. Add the same capability when using the source-highlight library. Tested on x86_64-linux. Verified that it works by: - making get_language_name return nullptr for language_c, and - checking that source-highlight still manages to highlight a hello world. Reviewed-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> PR cli/30966 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966
2023-10-20Don't include cooked-index.h from dwarf2/read.hTom Tromey2-1/+1
dwarf2/read.h includes cooked-index.h, but it doesn't need to. This patch removes the inclusion from this header, and adds one to index-write.c to make up for the absence.
2023-10-20gas: testsuite: microblaze: cosmetic fixNeal Frager1-1/+1
This patch makes a cosmetic change to the reloc_weaksym.s by making the bneid instruction all lower case like all of the other instructions in the example. Signed-off-by: Neal Frager <neal.frager@amd.com> Signed-off-by: Michael J. Eager <eager@eagercon.com>
2023-10-20libctf: fix creation-time parent/child dict confusionsNick Alcock17-20/+322
The fixes applied a few years ago to resolve confusions between parent and child dicts at lookup time also apply in various forms to creation. In general, if you have a type in a parent dict ctf_imported into a child and you do something to it, and the parent dict is writable (created via ctf_create, not opened via ctf_open*) it should work just the same to make changes to that type via a child dict as it does to make the change to the parent dict directly -- and nothing you're prohibited from doing to the parent dict when done directly should be allowed just because you're doing it via a child. Specifically, the following don't work when doing things from the child, but should: - adding a member of a type in the parent to a struct or union in the parent via ctf_add_member or ctf_add_member_offset: this yields ECTF_BADID - adding a member of a type in the parent to a struct or union in the parent via ctf_add_member_encoded: this dumps core (!). - adding an enumerand to an enumerator in the parent: this yields ECTF_BADID - setting the properties of an array in the parent via ctf_set_array; this yields ECTF_BADID Relatedly, some things work when doing things via a child that should fail, yielding a CTF dictionary with invalid content (readable, but meaningless): in particular, you can add a child type to a struct in the parent via any of the ctf_add_member* family and nothing complains at all, even though you should never be able to add references to children to parents (since any given parent can be associated with many different children). A family of tests is added to check each of these cases independently, since some can result in coredumps and it would be nice to test the other cases even if some dump core. They use a common library to do all the actual work. The set of affected API calls was determined by code inspection (auditing all calls to ctf_dtd_lookup): it's possible that I missed a few, but I doubt it, since other cases use ctf_lookup* functions, which already climb to the parent where appropriate. libctf/ChangeLog: PR libctf/30985 * ctf-create.c (ctf_dtd_lookup): Traverse to parents if necessary. (ctf_set_array): Likewise. Report errors on the child; require both parent and child to be writable. (ctf_add_enumerator): Likewise. (ctf_add_member_offset): Likewise. Prohibit addition of child types to structs in the parent. (ctf_add_member_encoded): Do not dereference a NULL dtd: report ECTF_BADID instead. * ctf-string.c (ctf_str_add_ref_internal): Report ENOMEM on the dict if addition of a string ref fails. * testsuite/libctf-writable/parent-child-dtd-crash-lib.c: New library. * testsuite/libctf-writable/parent-child-dtd-enum.*: New test. * testsuite/libctf-writable/parent-child-dtd-enumerator.*: New test. * testsuite/libctf-writable/parent-child-dtd-member-encoded.*: New test. * testsuite/libctf-writable/parent-child-dtd-member-offset.*: New test. * testsuite/libctf-writable/parent-child-dtd-set-array.*: New test. * testsuite/libctf-writable/parent-child-dtd-struct.*: New test. * testsuite/libctf-writable/parent-child-dtd-union.*: New test.
2023-10-20bfd: microblaze: Add 32_NONE reloc typeNeal Frager9-3/+51
This patch adds the R_MICROBLAZE_32_NONE relocation type. This is a 32-bit reloc that stores the 32-bit pc relative value in two words (with an imm instruction). Add test case to gas test suite. Signed-off-by: Neal Frager <neal.frager@amd.com> Signed-off-by: Michael J. Eager <eager@eagercon.com>
2023-10-20[gdb/symtab] Fix more style issues in v9 .gdb_index section supportTom de Vries5-9/+9
I noticed a few more style issues in commit 8b9c08eddac ("[gdb/symtab] Add name_of_main and language_of_main to the DWARF index"), after checking it with gcc's check_GNU_style.{sh,py}. Fix these. Build on x86_64-linux.
2023-10-19opcodes: microblaze: Fix bit masking bugNeal Frager3-8/+11
There is currently a bug in the bit masking for the barrel shift instructions because the bit mask is not including all of the register bits which must be zero. With this patch, the disassembler can be sure that the 32-bit value is indeed a barrel shift instruction and not a data value in memory. This fix can be verified by assembling and disassembling the following: .text .long 0x65005f5f With this patch, the bug is fixed, and the objdump will know that 0x65005f5f is not a barrel shift instruction. Signed-off-by: Neal Frager <neal.frager@amd.com> Signed-off-by: Michael J. Eager <eager@eagercon.com>
2023-10-20Automatic date update in version.inGDB Administrator1-1/+1
2023-10-19Fix race in DWARF readerTom Tromey3-25/+41
The recent change to record the DWARF language in the per-CU data yielded a race warning in my testing: ThreadSanitizer: data race ../../binutils-gdb/gdb/dwarf2/read.c:21779 in prepare_one_comp_unit This patch fixes the bug by applying the same style of fix that was done for the ordinary (gdb) language. I wonder if this code could be improved. Requiring an atomic for the language in particular seems unfortunate, as it is often consulted during index finalization. However, I haven't investigated this. Regression tested on x86-64 Fedora 38. Reviewed-by: Tom de Vries <tdevries@suse.de>
2023-10-20PR30984, assertion fail elf.c:8485Alan Modra1-0/+1
PR 30984 * ldelf.c (ldelf_place_orphan): Don't allow bfd_abs_section as a potential output section.
2023-10-19gdb: fix no-expat build of solib-target.cSimon Marchi1-2/+2
Fixes: CXX solib-target.o /home/smarchi/src/binutils-gdb/gdb/solib-target.c:57:8: error: ‘lm_info_vector’ does not name a type 57 | static lm_info_vector | ^~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/solib-target.c: In function ‘intrusive_list<shobj> solib_target_current_sos()’: /home/smarchi/src/binutils-gdb/gdb/solib-target.c:244:7: error: ‘solib_target_parse_libraries’ was not declared in this scope 244 | = solib_target_parse_libraries (library_document->data ()); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: Ib477d3343b401017d79729118242143bc95f24b2
2023-10-19ld: fix typo in ld.texi metdata->metadataJose E. Marchesi2-1/+5
2023-10-19gdb: rename struct so_list to shobjSimon Marchi25-128/+126
Now that so_list lists are implemented using intrusive_list, it doesn't really make sense for the element type to be named "_list". Rename to just `struct shobj` (`struct so` was deemed to be not greppable enough). Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: remove free_so functionSimon Marchi3-35/+5
Remove this function, replace it with deleting the so_list in callers. Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: don't call so_list::clear in free_soSimon Marchi1-1/+0
I think this `so.clear ()` call is not useful. - so_list::clear deletes some things that now get automatically deleted when the so_list gets deleted right after in free_so. - so_list::clear resets some scalar fields of so_list, which we don't really care about since the so_list gets deleted right after. - so_list::clear calls target_so_ops::clear_so, of which there is a single implementation, svr4_clear_so. That implementation just resets a field in lm_info_svr4, which we don't care about, as it will get deleted when the so_list gets deleted right after. Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: link so_list using intrusive_listSimon Marchi12-252/+178
Replace the hand-made linked list implementation with intrusive_list, simplying management of list items. Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make so_list::{so_original_name,so_name} std::stringsSimon Marchi13-80/+68
Change these two fields, simplifying memory management and copying. Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make so_list::abfd a gdb_bfd_ref_ptrSimon Marchi5-14/+11
Change the field from a `bfd *` to a gdb_bfd_ref_ptr to automatically manage the reference. Change-Id: I3ace18bea985bc194c5e67bb559eec567e258950 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make so_list::sections not a pointerSimon Marchi2-13/+7
Make the field a vector directly, instead of a pointer to a vector. This was needed when so_list had to be a trivial type, which is not the case anymore. Change-Id: I79a8378ce0d0d1e2206ca08a273ebf332cb3ba14 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: remove target_section_table typedefSimon Marchi17-51/+47
Remove this typedef. I think that hiding the real type (std::vector) behind a typedef just hinders readability. Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make clear_so a method of struct so_listSimon Marchi2-21/+24
... just because it seems to make sense to do so. Change-Id: Ie283c92d9b90c54e3deee96a43c6a942d8b5910b Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make so_list::lm_info a unique_ptrSimon Marchi10-31/+40
Make it a unique_ptr, so it gets automatically deleted when the so_list is deleted. Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: remove lm_info_vector typedefSimon Marchi1-9/+9
I think this typedef hinders readability. First, it's not well named (it's not clear it contains lm_info_target objects). And hiding the fact that it contains unique pointers is not very useful either. I was looking at the code in solib_target_current_sos where the unique pointers get moved from the vector, and it wasn't obvious at all what the source of the move was. Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make solib-rocm not use so_list internallySimon Marchi1-50/+42
Same rationale as the previous patch, but for solib-rocm. - Introduce rocm_so, which is a name a unique_name (see comment in rocm_update_solib_list for that) and a unique_ptr to the lm_info_svr4. - Change the internal lists from so_list lists to vectors of rocm_so. - Remove rocm_free_solib_list, as everything is automatic now. - Replace rocm_solib_copy_list with so_list_from_rocm_sos. Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make solib-svr4 not use so_list internallySimon Marchi2-177/+100
A subsequent patch makes use of non-trivial types in struct so_list. This trips on the fact that svr4_copy_library_list uses memcpy to copy so_list objects: so_list *newobj = new so_list; memcpy (newobj, src, sizeof (struct so_list)); solib-svr4 maintains lists of so_list objects in its own internal data structures. When requested to return a list of so_list objects (through target_so_ops::current_sos), it duplicates the internal so_list lists, using memcpy. When changing so_list to make it non-trivial, we would need to replace this use of memcpy somehow. That would mean making so_list copyable, with all the complexity that entails, just to satisfy this internal usage of solib-svr4 (and solib-rocm, which does the same). Change solib-svr4 to use its own data type for its internal lists. The use of so_list is a bit overkill anyway, as most fields of so_list are irrelevant for this internal use. - Introduce svr4_so, which contains just an std::string for the name and a unique_ptr for the lm_info. - Change the internal so_list lists to be std::vector<svr4_so>. Vector seems like a good choice for this, we don't need to insert/remove elements in the middle of these internal lists. - Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as everything is managed automatically now. - Replace svr4_copy_library_list (which duplicated internal lists in order to return them to the core) with so_list_from_svr4_sos, which creates an so_list list from a vector of svr4_so. - Generalize svr4_same a bit, because find_debug_base_for_solib now needs to compare an so_list and an svr4_so to see if they are the same. Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: use gdb::checked_static_cast when casting lm_infoSimon Marchi8-19/+19
Now that the lm_info class hierarchy has a virtual destructor and therefore a vtable, use checked_static_cast instead of C-style cases to ensure (when building in dev mode) that we're casting to the right kind of lm_info. Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: remove target_so_ops::free_soSimon Marchi9-77/+13
target_so_ops::free_so is responsible for freeing the specific lm_info object. All implementations basically just call delete. Remove that method, make the destructor of lm_info virtual, and call delete directly from the free_so function. Make the sub-classes final, just because it's good practice. Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: rename lm_info_base to lm_infoSimon Marchi7-8/+8
The base class doesn't need to have "_base" in its name, all the sub-classes have a specific suffix. Change-Id: I87652105cfedd87898770a81f0eda343ff7f2bdb Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: allocate so_list with new, deallocate with deleteSimon Marchi9-34/+26
Initialize all fields in the class declaration, change allocations to use "new", change deallocations to use "delete". This is needed by a subsequent patches that use C++ stuff in so_list. Change-Id: I4b140d9f1ec9ff809554a056f76e3eb2b9e23222 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make get_cbfd_soname_build_id staticSimon Marchi2-9/+4
It is only used in solib.c. Change-Id: I43461d13d84d65c4f6913d4033678d8983b9910b Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdbsupport: use "reference" and "pointer" type aliases in intrusive_listSimon Marchi1-14/+14
It seems to me like the code should used the defined type aliases, for consistency. Change-Id: Ib52493ff18ad29464405275bc10a0c6704ed39e9 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: replace some so_list parameters to use referencesSimon Marchi23-191/+183
A subsequent patch changes so_list to be linked using intrusive_list. Iterating an intrusive_list yields some references to the list elements. Convert some functions accepting so_list objects to take references, to make things easier and more natural. Add const where possible and convenient. Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
generated by cgit v1.1 at 2024-11-26 14:56:26 +0000