aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-07-12[gdb/symtab] Add dwarf2_cu::lang ()Tom de Vries3-100/+107
The cu->per_cu->lang field was added to carry information from the initial partial symtabs phase to the symtab expansion phase, for the benefit of a particular optimization in process_imported_unit_die. Other uses have been added, but since the first phase now has been parallelized, those have become problematic and sources of race conditions. Fix this by adding dwarf2_cu::lang () and using it where we can to replace cu->per_cu->lang () with cu->lang (). Also assert in dwarf2_cu::lang () that we're not returning language_unknown. Tested on x86_64-linux.
2022-07-12LTO plugin: sync header file with GCCMartin Liska1-0/+33
include/ChangeLog: * plugin-api.h (enum ld_plugin_tag): Sync with GCC.
2022-07-12[gdb/record] Support recording of getrandomTom de Vries10-1/+116
Add missing support for recording of linux syscall getrandom. Tested on x86_64-linux with native and target board unix/-m32. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22081
2022-07-12gdbserver: LoongArch: Add floating-point supportTiezhu Yang1-0/+32
This commit adds floating-point support for LoongArch gdbserver. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-07-12gdb: LoongArch: Add floating-point supportTiezhu Yang9-20/+300
This commit adds floating-point support for LoongArch gdb. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-07-12[gdb/testsuite] Run two test-cases with ASAN_OPTIONS=verify_asan_link_order=0Tom de Vries2-2/+14
When building gdb with -fsanitize=address we run into: ... builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 -data-directory \ build/gdb/data-directory^M ==10637==ASan runtime does not come first in initial library list; you \ should either link runtime to your application or manually preload it with \ LD_PRELOAD.^M ERROR: GDB process no longer exists ... Prevent the ASan runtime error by using ASAN_OPTIONS=verify_asan_link_order=0. This makes both test-cases pass. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29358
2022-07-12[gdb/testsuite] Add tsan-suppressions.txtTom de Vries2-0/+44
Add a new file tsan-suppressions.txt, to suppress the "unlock unlocked mutex" problem in ncurses, filed in PR29328. The file is added to the TSAN_OPTIONS in lib/gdb.exp. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29328
2022-07-12[gdb/build] Fix build with gcc 4.8.5Tom de Vries1-0/+4
When building gdb with gcc 4.8.5, we run into problems due to unconditionally using: ... gdb_static_assert (std::is_trivially_copyable<packed>::value); ... in gdbsupport/packed.h. Fix this by guarding the usage with HAVE_IS_TRIVIALLY_COPYABLE. Tested by doing a full gdb build with gcc 4.8.5.
2022-07-12Fix -fsanitize=thread for per_cu fieldsTom de Vries2-9/+14
When building gdb with -fsanitize=thread and gcc 12, and running test-case gdb.dwarf2/dwz.exp, we run into a data race between: ... Read of size 1 at 0x7b200000300d by thread T2:^M #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \ (gdb+0x82ec95)^M ... and: ... Previous write of size 1 at 0x7b200000300d by main thread:^M #0 prepare_one_comp_unit gdb/dwarf2/read.c:23588 (gdb+0x86f973)^M ... In other words, between: ... if (this_cu->reading_dwo_directly) ... and: ... cu->per_cu->lang = pretend_language; ... Likewise, we run into a data race between: ... Write of size 1 at 0x7b200000300e by thread T4: #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720) ... and: ... Previous read of size 1 at 0x7b200000300e by main thread: #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \ (gdb+0x82edab) ... In other words, between: ... this_cu->unit_type = DW_UT_partial; ... and: ... if (this_cu->reading_dwo_directly) ... Likewise for the write to addresses_seen in cooked_indexer::check_bounds and a read from is_dwz in dwarf2_find_containing_comp_unit for test-case gdb.dwarf2/dw2-dir-file-name.exp and target board cc-with-dwz-m. The problem is that the written fields are part of the same memory location as the read fields, so executing a read and write in different threads is undefined behavour. Making the written fields separate memory locations, using the new struct packed template fixes this. The set of fields has been established experimentally to be the minimal set to get rid of this type of -fsanitize=thread errors, but more fields might require the same treatment. Looking at the properties of the lang field, unlike dwarf_version it's not available in the unit header, so it will be set the first time during the parallel cooked index reading. The same holds for unit_type, and likewise for addresses_seen. dwarf2_per_cu_data::addresses_seen is moved so that the bitfields that currently follow it can be merged in the same memory location as the bitfields that currently precede it, for better packing. Tested on x86_64-linux. Co-Authored-By: Pedro Alves <pedro@palves.net> Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532
2022-07-12Introduce struct packed templatePedro Alves1-0/+90
When building gdb with -fsanitize=thread and gcc 12, and running test-case gdb.dwarf2/dwz.exp, we run into a few data races. For example, between: ... Write of size 1 at 0x7b200000300e by thread T4: #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720) ... and: ... Previous read of size 1 at 0x7b200000300e by main thread: #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \ (gdb+0x82edab) ... In other words, between: ... this_cu->unit_type = DW_UT_partial; ... and: ... if (this_cu->reading_dwo_directly) ... The problem is that the written fields are part of the same memory location as the read fields, so executing a read and write in different threads is undefined behavour. Making the written fields separate memory locations, like this: ... struct { ENUM_BITFIELD (dwarf_unit_type) unit_type : 8; }; ... fixes it, however that also increases the size of struct dwarf2_per_cu_data, because it introduces padding due to alignment of these new structs, which align on the natural alignment of the specified type of their fields. We can fix that with __attribute__((packed)), like so: struct { ENUM_BITFIELD (dwarf_unit_type) unit_type : 8 __attribute__((packed)); }; but to avoid having to write that in several places and add suitable comments explaining how that concoction works, introduce a new struct packed template that wraps/hides this. Instead of the above, we'll be able to write: packed<dwarf_unit_type, 1> unit_type; Note that we can't change the type of dwarf_unit_type, as that is defined in include/, and shared with other projects, some of those written in C. This patch just adds the struct packed type. Following patches will make use of it. One of those patches will want to wrap a struct packed in an std::atomic, like: std::atomic<std::packed<language, 1>> m_lang; so the new gdbsupport/packed.h header adds some operators to make comparisions between that std::atomic and the type that the wrapped struct packed wraps work, like in: if (m_lang == language_c) It would be possible to implement struct packed without using __attribute__((packed)), by having it store an array of bytes of the appropriate size instead, however that would make it less convenient to debug GDB. The way it's implemented, printing a struct packed variable just prints its field using its natural type, which is particularly useful if the type is an enum. I believe that __attribute__((packed)) is supported by all compilers that are able to build GDB. Even a few BFD headers use on ATTRIBUTE_PACKED on external types: include/coff/external.h: } ATTRIBUTE_PACKED include/coff/external.h:} ATTRIBUTE_PACKED ; include/coff/external.h:} ATTRIBUTE_PACKED ; include/coff/pe.h:} ATTRIBUTE_PACKED ; include/coff/pe.h:} ATTRIBUTE_PACKED; include/elf/external.h:} ATTRIBUTE_PACKED Elf_External_Versym; It is not possible to build GDB with MSVC today, but if it could, that would be one compiler that doesn't support this attribute. However, it supports packing via pragmas, so there's a way to cross that bridge if we ever get to it. I believe any compiler worth its salt supports some way of packing. In any case, the worse that happens without the attribute is that some types become larger than ideal. Regardless, I've added a couple static assertions to catch such compilers in action: /* Ensure size and aligment are what we expect. */ gdb_static_assert (sizeof (packed) == Bytes); gdb_static_assert (alignof (packed) == 1); Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532
2022-07-12PowerPC md_end: Don't htab_delete(NULL)Alan Modra1-10/+8
It might be possible to hit md_end before md_begin is called, don't segfault if so. Also, remove a useless check. * gas/config/tc-ppc.c (insn_calloc): Remove needless overflow check. (ppc_md_end): Check ppc_hash before deleting. Clear ppc_hash.
2022-07-12PR29355, ld segfaults with -r/-q and custom-named section .rela*Alan Modra1-4/+4
The bug testcase uses an output section named .rel or .rela which has input .data sections mapped to it. The input .data section has relocations. When counting output relocations SHT_REL and SHT_RELA section reloc_count is ignored, with the justification that reloc sections themselves can't have relocations and some backends use reloc_count in reloc sections. However, the test wrongly used the output section type (which normally would match input section type). Fix that. Note that it is arguably wrong for ld to leave the output .rel/.rela section type as SHT_REL/SHT_RELA when non-empty non-reloc sections are written to it, but I'm not going to change that since it might be useful to hand-craft relocs in a data section that is then written to a SHT_REL/SHT_RELA output section. PR 29355 * elflink.c (bfd_elf_final_link): Use input section type rather than output section type to determine whether to exclude using reloc_count from that section.
2022-07-12gdb/csky complete csky_dwarf_reg_to_regnumJiangshuai Li2-3/+26
For csky arch, the correspondence between Dwarf registers and GDB registers are as follows: dwarf regnos 0~31 ==> gdb regs r0~r31 dwarf regno CSKY_HI_REGNUM(36) ==> gdb reg hi dwarf regno CSKY_LO_REGNUM(37) ==> gdb reg hi dwarf regno CSKY_PC_REGNUM(72) ==> gdb reg pc dwarf regnos FV_PSEUDO_REGNO_FIRST(74)~FV_PSEUDO_REGNO_LAST(201) ==> gdb regs s0~s127 (pseudo regs for float and vector regs) other dwarf regnos have no corresponding gdb regs to them.
2022-07-12Automatic date update in version.inGDB Administrator1-1/+1
2022-07-11Always emit =thread-exited notifications, even if silentPedro Alves3-3/+96
[Note: the testcased added by this commit depends on https://sourceware.org/pipermail/gdb-patches/2022-June/190259.html, otherwise GDB just crashes when detaching the core] Currently, in MI, =thread-created are always emitted, like: =thread-group-started,id="i1",pid="195680" =thread-created,id="1",group-id="i1" ... but on teardown, if the target uses exit_inferior_silent, then you'll only see the inferior exit notification (thread-group-exited), no notification for threads. The core target is one of the few targets that use exit_inferior_silent. Here's an example session: -target-select core $corefile =thread-group-started,id="i1",pid="195680" =thread-created,id="1",group-id="i1" ... ^connected,frame=.... (gdb) -target-detach =thread-group-exited,id="i1" ^done (gdb) This imbalance of emitting =thread-created but then not =thread-exited seems off to me. (And, it complicates changes I want to do to centralize emitting thread exit notifications for the CLI, which is why I'm looking at this.) And then, since most other targets use exit_inferior instead of exit_inferior_silent, MI is already emitting =thread-exited notifications when tearing down an inferior, for most targets. This commit makes MI always emit the =thread-exited notifications, even for exit_inferior_silent. Afterwards, when debugging a core, MI outputs: (gdb) -target-detach =thread-exited,id="1",group-id="i1" << new line =thread-group-exited,id="i1" ^done (gdb) Surprisingly, there's no MI testcase debugging a core file. This commit adds the first. Change-Id: I5100501a46f07b6bbad3e04d120c2562a51c93a4
2022-07-11Fix core-file -> detach -> crash (corefiles/29275)Pedro Alves2-6/+33
After loading a core file, you're supposed to be able to use "detach" to unload the core file. That unfortunately regressed starting with GDB 11, with these commits: 1192f124a308 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses 408f66864a1a - detach in all-stop with threads running resulting in a GDB crash: ... Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899 2899 if (proc_target->commit_resumed_state) (top-gdb) bt #0 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899 #1 0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023 #2 0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049 #3 0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791 #4 0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95 #5 0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514 #6 0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699 The code that crashes looks like: static void maybe_set_commit_resumed_all_targets () { scoped_restore_current_thread restore_thread; for (inferior *inf : all_non_exited_inferiors ()) { process_stratum_target *proc_target = inf->process_target (); if (proc_target->commit_resumed_state) ^^^^^^^^^^^ With 'proc_target' above being null. all_non_exited_inferiors filters out inferiors that have pid==0. We get here at the end of detach_command, after core_target::detach has already run, at which point the inferior _should_ have pid==0 and no process target. It is clear it no longer has a process target, but, it still has a pid!=0 somehow. The reason the inferior still has pid!=0, is that core_target::detach just unpushes, and relies on core_target::close to actually do the getting rid of the core and exiting the inferior. The problem with that is that detach_command grabs an extra strong reference to the process stratum target, so the unpush_target inside core_target::detach doesn't actually result in a call to core_target::close. Fix this my moving the cleaning up the core inferior to a shared routine called by both core_target::close and core_target::detach. We still need to cleanup the inferior from within core_file::close because there are paths to it that want to get rid of the core without going through detach. E.g., "core-file" -> "run". This commit includes a new test added to gdb.base/corefile.exp to cover the "core-file core" -> "detach" scenario. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29275 Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893
2022-07-11Fix non-existent "@var{thread-id}" in stop reply descriptionsPedro Alves1-11/+9
In the description of stop replies, where the "thread" register is explained, and where the fork and vfork stop reasons are detailed, there are references to "@var{thread-id}", but such variable does not actually exist. This commit fixes it. Change-Id: If679944aaf15f6f64aabe506339a9e7667864cab
2022-07-11Try a couple PAuth compilation flags for gdb.arch/aarch64-pauth.expLuis Machado1-2/+17
The -msign-return-address switch has been dropped from GCC, but some older compiler may still support it. Make sure we try both -msign-return-address and -mbranch-protection before bailing out when running gdb.arch/aarch64-pauth.exp.
2022-07-11gdb: add support for disassembler styling using libopcodesAndrew Burgess6-26/+439
This commit extends GDB to make use of libopcodes styling support where available, currently this is just i386 based architectures, and RISC-V. For architectures that don't support styling using libopcodes GDB will fall back to using the Python Pygments package, when the package is available. The new libopcodes based styling has the disassembler identify parts of the disassembled instruction, e.g. registers, immediates, mnemonics, etc, and can style these components differently. Additionally, as the styling is now done in GDB we can add settings to allow the user to configure which colours are used right from the GDB CLI. There's some new maintenance commands: maintenance set libopcodes-styling enabled on|off maintenance show libopcodes-styling These can be used to manually disable use of libopcodes styling. This is a maintenance command as it's not anticipated that a user should need to do this. But, this could be useful for testing, or, in some rare cases, a user might want to override the Python hook used for disassembler styling, and then disable libopcode styling so that GDB falls back to using Python. Right now I would consider this second use case a rare situation, which is why I think a maintenance command is appropriate. When libopcodes is being used for styling then the user can make use of the following new styles: set/show style disassembler comment set/show style disassembler immediate set/show style disassembler mnemonic set/show style disassembler register The disassembler also makes use of the 'address' and 'function' styles to style some parts of the disassembler output. I have also added the following aliases though: set/show style disassembler address set/show style disassembler symbol these are aliases for: set/show style address set/show style function respectively, and exist to make it easier for users to discover disassembler related style settings. The 'address' style is used to style numeric addresses in the disassembler output, while the 'symbol' or 'function' style is used to style the names of symbols in disassembler output. As not every architecture supports libopcodes styling, the maintenance setting 'libopcodes-styling enabled' has an "auto-off" type behaviour. Consider this GDB session: (gdb) show architecture The target architecture is set to "auto" (currently "i386:x86-64"). (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "on". the setting defaults to "on" for architectures that support libopcodes based styling. (gdb) set architecture sparc The target architecture is set to "sparc". (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off" (not supported on architecture "sparc") the setting will show as "off" if the user switches to an architecture that doesn't support libopcodes styling. The underlying setting is still "on" at this point though, if the user switches back to i386:x86-64 then the setting would go back to being "on". (gdb) maintenance set libopcodes-styling enabled off (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off". now the setting is "off" for everyone, even if the user switches back to i386:x86-64 the setting will still show as "off". (gdb) maintenance set libopcodes-styling enabled on Use of libopcodes styling not supported on architecture "sparc". (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off". attempting to switch the setting "on" for an unsupported architecture will give an error, and the setting will remain "off". (gdb) set architecture auto The target architecture is set to "auto" (currently "i386:x86-64"). (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off". (gdb) maintenance set libopcodes-styling enabled on (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "on". the user will need to switch back to a supported architecture before they can one again turn this setting "on".
2022-07-11gdb: have gdb_disassemble_info carry 'this' in its stream pointerAndrew Burgess2-33/+67
The gdb_disassemble_info class is a wrapper around the libopcodes disassemble_info struct. The 'stream' field of disassemble_info is passed as an argument to the fprintf_func and fprintf_styled_func callbacks when the disassembler wants to print anything. Previously, GDB would store a pointer to a ui_file object in the 'stream' field, then, when the disassembler wanted to print anything, the content would be written to the ui_file object. An example of an fprintf_func callback, from gdb/disasm.c is: int gdb_disassembler::dis_asm_fprintf (void *stream, const char *format, ...) { /* Write output to STREAM here. */ } This is fine, but has one limitation, within the print callbacks we only have access to STREAM, we can't access any additional state stored within the gdb_disassemble_info object. Right now this isn't a problem, but in a future commit this will become an issue, how we style the output being written to STREAM will depend on the state of the gdb_disassemble_info object, and this state might need to be updated, depending on what is being printed. In this commit I propose changing the 'stream' field of the disassemble_info to carry a pointer to the gdb_disassemble_info sub-class, rather than the stream itself. We then have the two sub-classes of gdb_disassemble_info to consider, the gdb_non_printing_disassembler class never cared about the stream, previously, for this class, the stream was nullptr. With the change to make stream be a gdb_disassemble_info pointer, no further updates are needed for gdb_non_printing_disassembler. The other sub-class is gdb_printing_disassembler. In this case the sub-class now carries around a pointer to the stream object. The print callbacks are updated to cast the incoming stream object back to a gdb_printing_disassembler, and then extract the stream. This is purely a refactoring commit. A later commit will add additional state to the gdb_printing_disassembler, and update the print callbacks to access this state. There should be no user visible changes after this commit.
2022-07-11[gdb/symtab] Fix data race in per_cu->lengthTom de Vries3-25/+41
With gdb build with -fsanitize=thread and test-case gdb.dwarf2/dw4-sig-types.exp and target board cc-with-dwz-m we run into a data race between: ... Write of size 4 at 0x7b2800002268 by thread T4:^M #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6236 \ (gdb+0x82f525)^M ... and this read: ... Previous read of size 4 at 0x7b2800002268 by thread T1:^M #0 dwarf2_find_containing_comp_unit gdb/dwarf2/read.c:23444 \ (gdb+0x86e22e)^M ... In other words, between this write: ... this_cu->length = cu->header.get_length (); ... and this read: ... && mid_cu->sect_off + mid_cu->length > sect_off)) ... of per_cu->length. Fix this similar to the per_cu->dwarf_version case, by only setting it if needed, and otherwise verifying that the same value is used. [ Note that the same code is already present in the other cutu_reader constructor. ] Move this logic into into a member function set_length to make sure it's used consistenly, and make the field private in order to enforce access through the member functions, and rename it to m_length. This exposes (running test-case gdb.dwarf2/fission-reread.exp) that in fill_in_sig_entry_from_dwo_entry, the m_length field is overwritten. For now, allow for that exception. While we're at it, make sure that the length is set before read. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29344
2022-07-11[gdb/symtab] Use comp_unit_head::get_lengthTom de Vries1-1/+1
There's a spot in read_comp_units_from_section where we explictly use initial_length_size to get the total length: ... this_cu->length = cu_header.length + cu_header.initial_length_size; ... Instead, just use cu_header.get_length (). Tested on x86_64-linux.
2022-07-11Automatic date update in version.inGDB Administrator1-1/+1
2022-07-10Fix include guard naming for arch/aarch64-mte-linux.hLuis Machado1-3/+3
It should be ARCH_AARCH64_MTE_LINUX_H as opposed to ARCH_AARCH64_LINUX_H.
2022-07-10gdbserver: LoongArch: Add orig_a0 processingYouling Tang2-2/+4
Commit 736918239b16 ("gdb: LoongArch: add orig_a0 into register set") introduced orig_a0, similar processing needs to be done in gdbserver. At the same time, add orig_a0 related comments. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-07-10gdbserver: LoongArch: Simplify code with register number macrosYouling Tang3-31/+25
Move "enum loongarch_regnum" to gdb/arch/loongarch.h so that the macro definitions can be used in gdbserver/linux-loongarch-low.cc to simplify the code. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-07-10Automatic date update in version.inGDB Administrator1-1/+1
2022-07-09gas: tc-tic54x.c hash tablesAlan Modra2-139/+223
Cleaning up the subsym_hash memory is a real pain. Keys and values entered into the table are quite diverse. In some cases the key is allocated and thus needs to be freed, in others the key is a const string. Values are similar, and in some cases not even a string. Tidy this by inserting a new subsym_ent_t that describes key/value type. This meant the math_hash table was no longer needed. The patch also tidies how math functions are called, those that are supposed to return int now no longer return their value in a float. * config/tc-tic54x.c (math_hash): Delete. (subsym_proc_entry): Move earlier, make proc a union, merge with.. (math_proc_entry): ..this. Delete type. (math_procs): Merge into subsym_procs. (subsym_ent_t): New. Use this type in subsym_hash.. (stag_add_field_symbols, tic54x_var, tic54x_macro_info): ..here.. (md_begin, subsym_create_or_replace, subsym_lookup): ..and here.. (subsym_substitute): ..and here. Adjust subsym_proc_entry function calls. Free replacement when not returned. (subsym_get_arg): Adjust subsym_lookup. (free_subsym_ent, subsym_htab_create ): New functions, use when creating subsym_hash. (free_local_label_ent, local_label_htab_create): Similarly. (tic54x_remove_local_label): Delete. (tic54x_clear_local_labels): Simplify. (tic54x_asg): Use notes obstack to dup strings. (tic54x_eval): Likewise. (subsym_ismember): Likewise. (math_cvi, math_int, math_sgn): Return int. (tic54x_macro_start): Decrement macro_level before calling as_fatal. (tic54x_md_end): New function. * config/tc-tic54h.c (tic54x_md_end): Declare. (md_end): Define.
2022-07-09gas: use notes_calloc in string hashAlan Modra6-8/+9
Using notes_calloc means all of the string hash table memory should now be freed before gas exits, even though htab_delete isn't called. This also means that the hash table free_f and del_f must be NULL, because freeing notes obstack memory results in all more recently allocated notes memory being freed too. So hash table resizing won't free any memory, and will be a little faster. Also, htab_delete won't do anything (and be quick about it). Since htab_traverse can also resize hash tables (to make another traversal faster if the table is largely empty), stop that happening when only one traversal is done. * as.h: Reorder hash.h after symbols.h for notes_calloc decl. * hash.h (str_htab_create): Use notes_calloc. Do not free. * symbols.c (resolve_local_symbol_values): Don't resize during hash table traversal. * config/obj-elf.c (elf_frob_file_after_relocs): Likewise. * config/tc-ia64.c (ia64_adjust_symtab, ia64_frob_file): Likewise. * config/tc-nds32.c (nds32_elf_analysis_relax_hint): Likewise.
2022-07-09gas: target string hash tablesAlan Modra9-81/+45
This allocates entries added to the string hash tables on the notes obstack, so that at least those do not leak. A followup patch will switch over the str_hash allocation to notes_calloc, which is why I haven't implemented deleting all the target string hash tables. * config/obj-coff-seh.c (get_pxdata_name, alloc_pxdata_item): Use notes obstack for string hash table entries. * config/tc-alpha.c (get_alpha_reloc_tag, md_begin): Likewise. * config/tc-h8300.c (md_begin): Likewise. * config/tc-ia64.c (dot_rot, dot_pred_rel, dot_alias): Likewise. * config/tc-nds32.c (nds32_relax_hint): Likewise. * config/tc-riscv.c (riscv_init_csr_hash): Likewise. * config/tc-score.c (s3_insert_reg): Likewise. (s3_build_score_ops_hsh, s3_build_dependency_insn_hsh): Likewise. * config/tc-score7.c (s7_build_score_ops_hsh): Likewise. (s7_build_dependency_insn_hsh): Likewise. * config/tc-tic4x.c (tic4x_asg): Likewise.
2022-07-09arc gas: don't leak arc_opcode_hash memoryAlan Modra2-1/+23
The arc opcode hash table has entries that have a realloc'd field. This doesn't lend itself to obstack allocation, so freeing must be done with a purpose built hashtab del_f. * config/tc-arc.c (arc_opcode_free): New function. (md_begin): Pass the above as del_f to htab_create_alloc. (arc_md_end): New function. * config/tc-arc.h (arc_md_end): Declare. (md_end): Define.
2022-07-09i386 gas: don't leak op_hash or reg_hash memoryAlan Modra3-3/+13
This tidies memory used by the two x86 gas string hash tables before exiting. I'm using a two-pronged approach, firstly the obvious call to htab_delete plus telling the libiberty/hashtab.c infrastructure to free tuples generated by str_hash_insert, and secondly putting the x86 core_optab memory on the notes obstack. It would be possible to free core_optab memory by using a custom hash table del_f on x86, as I do for arc, but a later patch will move all the string hash memory to the notes obstack. * config/tc-i386.c (md_begin): Use notes_alloc for core_optab. (386_md_end): New function. * config/tc-i386.h (386_md_end): Declare. (md_end): Define. * hash.h (str_htab_create): Pass free as del_f.
2022-07-09ppc gas: don't leak ppc_hash memoryAlan Modra2-2/+37
* config/tc-ppc.c (insn_obstack): New. (insn_calloc): New function. (ppc_setup_opcodes): Use insn_obstack for ppc_hash. (ppc_md_end): New function. * config/tc-ppc.h (ppc_md_end): Declare (md_end): Define.
2022-07-09gas hash.h tidyAlan Modra2-30/+38
Only inline functions should be defined in hash.h, there's no benefit in having multiple copies of hash_string_tuple and eq_string_tuple. Also, use the table alloc_f when allocating tuples to be stored, so that these functions are usable with different memory allocation strategies. * hash.h (struct string_tuple, string_tuple_t): Move earlier. (string_tuple_alloc): Add table param, allocate using table alloc_f. (str_hash_insert): Adjust to suit. Call table->free_f when entry is not used. (hash_string_tuple, eq_string_tuple): Move to.. * hash.c: ..here.
2022-07-09gas: rename md_end to md_finishAlan Modra42-80/+84
Currently md_end is typically used for some final actions rather than freeing memory like other *_end functions. Rename it to md_finish, and rename target implementation. The renaming of target functions makes it possible to find them all with "grep md_finish", eg. md_mips_end is renamed to mips_md_finish, not md_mips_finish. This patch leaves a number of md_end functions unchanged, those that either do nothing or deallocate memory, and calls them late. The idea here is that target maintainers implement md_end functions to tidy memory, if anyone cares. Freeing persistent memory in gas is not at all important, except that it can hide more important memory leaks, those that happen once per some frequent gas operation, amongst these unimportant memory leaks. * as.c (main): Rename md_end to md_finish. * config/tc-alpha.c, * config/tc-alpha.h, * config/tc-arc.c, * config/tc-arc.h, * config/tc-arm.c, * config/tc-arm.h, * config/tc-csky.c, * config/tc-csky.h, * config/tc-ia64.c, * config/tc-ia64.h, * config/tc-mcore.c, * config/tc-mcore.h, * config/tc-mips.c, * config/tc-mips.h, * config/tc-mmix.c, * config/tc-mmix.h, * config/tc-msp430.c, * config/tc-msp430.h, * config/tc-nds32.c, * config/tc-nds32.h, * config/tc-ppc.c, * config/tc-ppc.h, * config/tc-pru.c, * config/tc-pru.h, * config/tc-riscv.c, * config/tc-riscv.h, * config/tc-s390.c, * config/tc-s390.h, * config/tc-sparc.c, * config/tc-sparc.h, * config/tc-tic4x.c, * config/tc-tic4x.h, * config/tc-tic6x.c, * config/tc-tic6x.h, * config/tc-v850.c, * config/tc-v850.h, * config/tc-xtensa.c, * config/tc-xtensa.h, * config/tc-z80.c, * config/tc-z80.h: Similarly. * output-file.c (output_file_close): Call md_end.
2022-07-09gas: set up notes obstack earlierAlan Modra3-11/+15
So that the notes obstack can be used for persistent storage in parse_args. * as.c (parse_args): Use notes_alloc and notes_strdup. (free_notes): New function. (main): Init notes obstack, and arrange to be freed on exit. * read.c (read_begin): Don't init notes obstack. (read_end): Free cond_obstack. * subsegs.c (subsegs_end): Don't free cond_obstack or notes.
2022-07-09gas: itbl_filesAlan Modra1-20/+2
itbl_files seems to be debug code. Get rid of it. * as.c (struct itbl_file_list): Delete. (itbl_files): Delete. (parse_args): Don't keep itbl_files list.
2022-07-09gas: free sy_hash, macro_hash and po_hashAlan Modra7-0/+33
* macro.c (macro_end): New function. * macro.h (macro_end): Declare. * read.c (read_end, poend): New functions. * read.h (read_end): Declare. * symbols.c (symbol_end): New function. * symbols.h (symbol_end): Declare. * output-file.c (output_file_close): Call new *_end functions.
2022-07-09dw2gencfi.c: use notes obstackAlan Modra1-12/+10
Use notes obstack for dwcfi_hash entries, and free table. Freeing the table makes memory checkers complain more about "definitely lost" memory as we've moved some from the "still reachable" category. That will be fixed with a later patch. * dw2gencfi.c (get_debugseg_name): Allocate on notes obstack. (alloc_debugseg_item): Likewise. (dwcfi_hash_find_or_make): Adjust failure path free. (cfi_finish): Delete dwfci_hash.
2022-07-09expr.c make_expr_symbol: use notes obstackAlan Modra1-1/+1
* expr.c (make_expr_symbol): Use notes_alloc.
2022-07-09read.c assign_symbol: use notes obstack for dummy listing fragAlan Modra1-1/+1
* read.c (assign_symbol): Use notes_calloc for dummy_frag.
2022-07-09read.c s_include: use notes obstack for pathAlan Modra1-4/+2
* read.c (s_include): Use notes obstack for path mem.
2022-07-09macro.c: use string hash from hash.h for macro_hashAlan Modra3-144/+29
Another case of duplicated hash.h code, the only minor difference being that macro->format_hash was created with 7 entries vs. str_hash with 16 entries. * macro.c (macro_init, define_macro): Use str_htab_create. (do_formals, define_macro, macro_expand_body): Use str_hash_insert (macro_expand_body): Use str_hash_find and str_hash_delete. (delete_macro): Likewise. (sub_actual, macro_expand, check_macro): Use str_hash_find. (expand_irp): Use str_htab_create and str_hash_insert. * macro.h (struct macro_struct): Tidy. (struct macro_hash_entry, macro_hash_entry_t, hash_macro_entry), (eq_macro_entry, macro_entry_alloc, macro_entry_find), (struct formal_hash_entry, formal_hash_entry_t), (hash_formal_entry, eq_formal_entry, formal_entry_alloc), (formal_entry_find): Delete. * config/tc-iq2000.c (iq2000_add_macro): Use str_htab_create and str_hash_insert.
2022-07-09read.c: use string hash from hash.h for po_hashAlan Modra1-56/+7
po_hash code duplicates the str_hash code in hash.h for no good reason. * read.c (struct po_entry, po_entry_t): Delete. (hash_po_entry, eq_po_entry, po_entry_alloc, po_entry_find): Delete. (pop_insert): Use str_hash_insert. (pobegin): Use str_htab_create. (read_a_source_file, s_macro): Use str_hash_find.
2022-07-09free read_symbol_name stringAlan Modra2-0/+5
read_symbol_name mallocs the string it returns. Free it when done. * read.c (read_symbol_name): Free name on error path. * config/tc-ppc.c (ppc_GNU_visibility): Free name returned from read_symbol_name. (ppc_extern, ppc_globl, ppc_weak): Likewise.
2022-07-09gas: output_file_closeAlan Modra4-15/+13
This is mostly a tidy with the aim of being able to free out_file_name, but it does fix a possible attempt to unlink the output file twice (not that that matters). * as.h (keep_it): New global. * as.c (keep_it): Delete. (close_output_file): Delete, merged into.. * output-file.c (output_file_close): ..here. Delete parameter. * output-file.h (output_file_close): Update prototype.
2022-07-09gas: utility notes memory alloc functionsAlan Modra3-10/+90
Makes it a little easier to use the notes obstack for persistent storage. * as.h (gas_mul_overflow): Define. * symbols.h (notes_alloc, notes_calloc, notes_memdup), (notes_strdup, notes_concat, notes_free): Declare. * symbols.c (notes_alloc, notes_calloc, notes_memdup), (notes_strdup, notes_concat, notes_free): New functions. (save_symbol_name): Use notes_strdup. (symbol_create, local_symbol_make, local_symbol_convert), (symbol_clone, decode_local_label_name): Use notes_alloc.
2022-07-09gas: arm -mwarn-syms duplicatesAlan Modra2-5/+3
arm gas is only supposed to warn once per symbol for -mwarn-syms, but doesn't because the str_hash_find added with commit 629310abec88 always returns NULL. That's so because the str_hash_insert inserts a NULL value for the key,value pair. Let str_hash_insert do the job instead. * config/tc-arm.c (arm_tc_equal_in_insn): Correct already_warned logic. * testsuite/gas/arm/pr18347.s: Modify to generate duplicate warning without this patch.
2022-07-09Regenerate with automake-1.15.1Alan Modra25-3737/+2263
Until we update the recommended versions of autoconf/automake, files should be regenerated with automake-1.15.1 and autoconf-2.69. That's not because we think those versions are golden, and newer versions are bad. It's simply because maintainers want to be able to update configury files without trouble, and if someone regenerates files with automake-1.16.5 then --enable-maintainer-mode builds will hit errors: checking that generated files are newer than configure... configure.ac:26: error: version mismatch. This is Automake 1.15.1, configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE configure.ac:26: comes from Automake 1.16.5. You should recreate configure.ac:26: aclocal.m4 with aclocal and run automake again. WARNING: 'automake-1.15' is probably too old. Correcting this requires regenerating the files by hand.
2022-07-09Automatic date update in version.inGDB Administrator1-1/+1