binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Simon Marchi	cb5dfff88e	gdb: add target_debug_printf and target_debug_printf_nofunc Add the `target_debug_printf` and `target_debug_printf_nofunc` macros and use them when outputting debug messages depending on `targetdebug`. I opted for `target_debug_printf_nofunc` to follow the current style where the function name is already printed, along with the arguments. Modify the debug printfs in the `debug_target` methods (generated by `make-target-delegates.py`) to use `target_debug_printf_nofunc` as well. This makes the "target" debug prints integrate nicely with the other debug prints that use the "new" debug print system: [infrun] proceed: enter [infrun] follow_fork: enter [target] -> multi-thread->record_will_replay (...) [target] <- multi-thread->record_will_replay (-1, 0) = false [target] -> multi-thread->supports_multi_process (...) [target] <- multi-thread->supports_multi_process () = true [infrun] follow_fork: exit ... Change-Id: Ide3c8c1b8a30e6d4c353a29cba911c7192de29ac Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Simon Marchi	8a8b6c53e1	gdb: make regcache::debug_print_register return a string Rename the method to `register_debug_string`. This makes it easier to introduce `target_debug_printf` in a subsequent patch. Change-Id: I5bb2d49476d17940d503e66f40762e3f1e3baabc Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Simon Marchi	b38f70086d	gdb: make debug_target use one-liners Turn the debug prints in debug_target's method to be one liners. For instance, change this: gdb_printf (gdb_stdlog, "<- %s->wait (", this->beneath ()->shortname ()); gdb_puts (target_debug_print_ptid_t (arg0), gdb_stdlog); gdb_puts (", ", gdb_stdlog); gdb_puts (target_debug_print_target_waitstatus_p (arg1), gdb_stdlog); gdb_puts (", ", gdb_stdlog); gdb_puts (target_debug_print_target_wait_flags (arg2), gdb_stdlog); gdb_puts (") = ", gdb_stdlog); target_debug_print_ptid_t (result); gdb_puts ("\n", gdb_stdlog); into this: gdb_printf (gdb_stdlog, "<- %s->wait (%s, %s, %s) = %s\n", this->beneath ()->shortname (), target_debug_print_ptid_t (arg0).c_str (), target_debug_print_target_waitstatus_p (arg1).c_str (), target_debug_print_target_wait_flags (arg2).c_str (), target_debug_print_ptid_t (result).c_str ()); This makes it possible for a subsequent patch to turn this gdb_printf call into a `target_debug_printf` call. Change-Id: I808202438972fac1bba2f8ccb63e66a4fcef20c9 Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Simon Marchi	a887499c6b	gdb: make target debug functions return std::string Change the functions in target-debug.h to return string representations in an std::string, such that they don't need to know how the printing part is done. This also helps the following patch that makes the debug prints in debug_target one-liners. Update target-delegates.c (through make-target-delegates.py) to do the printing. Add an overload of gdb_puts to avoid using `.c_str ()`. Change-Id: I55cbff1c1b03a3b24a81740e34c6ad41ac4f8453 Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Simon Marchi	559798f828	gdb: fix include for gdb_signal in target/waitstatus.h clangd tells me that the gdb_signals.h include in target/waitstatus.h is unused. This include was probably to give access to `enum gdb_signal`, but this is in fact defined in gdb/signals.h. Change the include to gdb/signals.h. Include gdbsupport/gdb_signals.h in some files that were relying on the transitive include. Change-Id: I6f4361b3d801394bf29abe8c1393aff110aa0ad6	2 years ago
Simon Marchi	ebb8507cee	gdb: convert target debug macros to functions Convert all the macros to static functions. Some macros were unused, and now that they are functions, got flagged by the compiler, so I omitted them. No behavior change expected. Change-Id: Ia88e61d95e29a0378901c71aa50df7c37d16bebe Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Simon Marchi	f74d62a1bc	gdb: add includes in target-debug.h Editing target-debug.h with clangd shows a bunch of errors. Add some includes to fix that (make target-debug.h include what it uses). Change-Id: I49075a171e6875fa516d6b2ce56b4a03ac7b3376	2 years ago
Nick Alcock	edc27e2d90	libctf: do not include undefined functions in libctf.ver libctf's version script is applied to two libraries: libctf.so, and libctf-nobfd.so. The latter library is a subset of the former which does not link to libbfd and does not include a few public entry points that use it (found in libctf-open-bfd.c). This means that some of the symbols in this version script only exist in one of the libraries it's applied to. A number of linkers dislike this: before now, only Solaris's linker caused serious problems, introducing NOTYPE-typed symbols when such things were found, but now LLD has started to complain as well: ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_arc_open' failed: symbol not defined ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_fdopen' failed: symbol not defined ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_open' failed: symbol not defined ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen' failed: symbol not defined ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen_ctfsect' failed: symbol not defined Rather than adding more and more whack-a-mole fixes for every linker we encounter that does this, simply exclude such symbols unconditionally, using the same trick we used to use for Solaris. (Well, unconditionally if we can use version scripts with this linker at all, which is not always the case.) Thanks to Nicholas Vinson for the original report and a fix very similar to this one (but not quite identical). libctf/ * configure.ac: Always exclude libctf symbols from libctf-nobfd's version script. * configure: Regenerated.	2 years ago
Nicholas Vinson	d8e1bca7eb	libctf: Remove undefined functions from ver. map Starting with ld.lld-17, ld.lld is invoked with the option --no-undefined-version enabled by default. Furthermore, The functions ctf_label_set() and ctf_label_get() are not defined. Their inclusion in libctf/libctf.ver causes ld.lld-17 to fail emitting the following error messages: ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined This patch fixes the issue by removing the symbol names from libctf/libctf.ver. [nca: fused in later commit that marked ctf_arc_open as libctf only as well. Added ChangeLog entry.] Signed-off-by: Nicholas Vinson <nvinson234@gmail.com> libctf/ * libctf.ver: drop nonexistent label functions: mark ctf_arc_open as libctf-only.	2 years ago
Nick Alcock	7e1368b58f	libctf: don't pass errno into ctf_err_warn so often The libctf-internal warning function ctf_err_warn() can be passed a libctf errno as a parameter, and will add its textual errmsg form to the passed-in error message. But if there is an error on the fp already, and this is specifically an error and not a warning, ctf_err_warn() will print the error out regardless: there's no need to pass in anything but 0. There are still a lot of places where we do ctf_err_warn (fp, 0, EFOO, ...); return ctf_set_errno (fp, 0, EFOO); I've left all of those alone, because fixing it makes the code a bit longer: but fixing the cases where no return is involved and the error has just been set on the fp itself costs nothing and reduces redundancy a bit. libctf/ * ctf-dedup.c (ctf_dedup_walk_output_mapping): Drop the errno arg. (ctf_dedup_emit): Likewise. (ctf_dedup_type_mapping): Likewise. * ctf-link.c (ctf_create_per_cu): Likewise. (ctf_link_deduplicating_close_inputs): Likewise. (ctf_link_deduplicating_one_symtypetab): Likewise. (ctf_link_deduplicating_per_cu): Likewise. * ctf-lookup.c (ctf_lookup_symbol_idx): Likewise. * ctf-subr.c (ctf_assert_fail_internal): Likewise.	2 years ago
Nick Alcock	b5ac272b87	libctf: fix leak in test This purely serves to make it easier to interpret valgrind output. No functional effect. libctf/ * testsuite/libctf-lookup/conflicting-type-syms.c: Free everything.	2 years ago
Nick Alcock	3b5e2d0e8d	libctf: add rewriting tests Now there's a chance of it actually working, we can add more tests for the long-broken dict read-and-rewrite cases. This is the first ever test for the (rarely-used, unpleasant, and until recently completely broken) ctf_gzwrite function. libctf/ * testsuite/libctf-regression/gzrewrite: New test. testsuite/libctf-regression/zrewrite*: Likewise.	2 years ago
Nick Alcock	a96a9ca953	libctf: fix a debugging typo libctf/ * ctf-lookup.c (ctf_symidx_sort): Fix a debugging typo.	2 years ago
Nick Alcock	9049b960f2	libctf: make ctf_lookup of symbols by name work in more cases In particular, we don't need a symbol table if we're looking up a symbol by name and that type of symbol has an indexed symtypetab, since in that case we get the name from the symtypetab index, not from the symbol table. This lets you do symbol lookups in unlinked object files and unlinked dicts written out via libctf's writeout functions. libctf/ * ctf-lookup.c (ctf_lookup_by_sym_or_name): Allow lookups by index even when there is no symtab.	2 years ago
Nick Alcock	0ebf1bdeed	libctf: improve handling of type dumping errors When dumping a type fails with an error, we want to emit a warning noting this: a warning because it's not fatal and we can continue. But warnings don't automatically print out the ctf_errno (because not all cases causing warnings set the errno at all), so we must do it at warning-emission time or lose track of what's gone wrong. libctf/ * ctf-dump.c (ctf_dump_format_type): Dump the underlying error on type dump failure.	2 years ago
Nick Alcock	eb244227d8	libctf: fix tiny dumping error Without this, you might get things like this in the output: Flags: 0xa (CTF_F_NEWFUNCINFO, , CTF_F_DYNSTR) Note the spurious comma. libctf/ * ctf-dump.c (ctf_dump_header): Fix comma emission.	2 years ago
Nick Alcock	483546ce4f	libctf: make ctf_serialize() actually serialize ctf_serialize() evolved from the old ctf_update(), which mutated the in-memory CTF dict to make all the dynamic in-memory types into static, unchanging written-to-the-dict types (by deserializing and reserializing it): back in the days when you could only do type lookups on static types, this meant you could see all the types you added recently, at the small, small cost of making it impossible to change those older types ever again and inducing an amortized O(n^2) cost if you actually wanted to add references to types you added at arbitrary times to later types. It also reset things so that ctf_discard() would throw away only types you added after the most recent ctf_update() call. Some time ago this was all changed so that you could look up dynamic types just as easily as static types: ctf_update() changed so that only its visible side-effect of affecting ctf_discard() remained: the old ctf_update() was renamed to ctf_serialize(), made internal to libctf, and called from the various functions that wrote files out. ... but it was still working by serializing and deserializing the entire dict, swapping out its guts with the newly-serialized copy in an invasive and horrible fashion that coupled ctf_serialize() to almost every field in the ctf_dict_t. This is totally useless, and fixing it is easy: just rip all that code out and have ctf_serialize return a serialized representation, and let everything use that directly. This simplifies most of its callers significantly. (It also points up another bug: ctf_gzwrite() failed to call ctf_serialize() at all, so it would only ever work for a dict you just ctf_write_mem()ed yourself, just for its invisible side-effect of serializing the dict!) This lets us simplify away a bunch of internal-only open-side functionality for overriding the syn_ext_strtab and some just-added functionality for forcing in an existing atoms table, without loss of functionality, and lets us lift the restriction on reserializing a dict that was ctf_open()ed rather than being ctf_create()d: it's now perfectly OK to open a dict, modify it (except for adding members to existing structs, unions, or enums, which fails with -ECTF_RDONLY), and write it out again, just as one would expect. libctf/ * ctf-serialize.c (ctf_symtypetab_sect_sizes): Fix typos. (ctf_type_sect_size): Add static type sizes too. (ctf_serialize): Return the new dict rather than updating the existing dict. No longer fail for dicts with static types; copy them onto the start of the new types table. (ctf_gzwrite): Actually serialize before gzwriting. (ctf_write_mem): Improve forced (test-mode) endian-flipping: flip dicts even if they are too small to be compressed. Improve confusing variable naming. * ctf-archive.c (arc_write_one_ctf): Don't bother to call ctf_serialize: both the functions we call do so. * ctf-string.c (ctf_str_create_atoms): Drop serializing case (atoms arg). * ctf-open.c (ctf_simple_open): Call ctf_bufopen directly. (ctf_simple_open_internal): Delete. (ctf_bufopen_internal): Delete/rename to ctf_bufopen: no longer bother with syn_ext_strtab or forced atoms table, serialization no longer needs them. * ctf-create.c (ctf_create): Call ctf_bufopen directly. * ctf-impl.h (ctf_str_create_atoms): Drop atoms arg. (ctf_simple_open_internal): Delete. (ctf_bufopen_internal): Likewise. (ctf_serialize): Adjust. * testsuite/libctf-lookup/add-to-opened.c: Adjust now that this is supposed to work.	2 years ago
Nick Alcock	cf9da3b0b6	libctf: rethink strtab writeout This commit finally adjusts strtab writeout so that repeated writeouts, or writeouts of a dict that was read in earlier, only sorts the portion of the strtab that was newly added. There are three intertwined changes here: - pull the contents of strtabs from newly ctf_bufopened dicts into the atoms table, so that future additions will reuse the existing offset etc rather than adding new identical strings - allow the internal ctf_bufopen done by serialization to contribute its existing atoms table, so that existing atoms can be used for the remainder of the open process (like name table construction): this atoms table currente gets thrown away in the mass reassignment done later in ctf_serialize in any case, but it needs to be there during the open. - rewrite ctf_str_write_strtab so that a) it uses iterators rather than ctf__iter, reducing pointless structures which serve no other purpose than to implement ordinary variable scope, but more clunkily, and b) retains the existing strtab on the front of the new one, with its sort retained, rather than resorting, so all existing already-written strtab offsets remain valid across the call. This latter change finally permits repeated serializations, and reserializations of ctf_open()ed dicts, to work, but for now we keep the code that prevents that because serialization is about to change again in a way that will make it more obvious that doing such things is safe, and we can take it out then. (There are also some smaller changes like moving the purge of the refs table into ctf_str_write_strtab(), since that's where the changes happen that invalidate it, rather than doing it in ctf_serialize(). We also prohibit something that has never worked, opening a dict and then reporting symbols to it via ctf_link_add_strtab() et al: you must do that to newly-created dicts which have had stuff ctf_link()ed into them. This is very unlikely ever to be a problem in practice: linkers just don't do that sort of thing.) libctf/ ctf-create.c (ctf_create): Add (temporary) atoms arg. * ctf-impl.h (struct ctf_dict.ctf_dynstrtab): New. (ctf_str_create_atoms): Adjust. (ctf_str_write_strtab): Likewise. (ctf_simple_open_internal): Likewise. * ctf-open.c (ctf_simple_open_internal): Add atoms arg. (ctf_bufopen): Likewise. (ctf_bufopen_internal): Initialize just enough of an atoms table: pre-init from the atoms arg if supplied. (ctf_simple_open): Adjust. * ctf-serialize.c (ctf_serialize): Constify the strtab. Move ref list purging into ctf_str_write_strtab. Initialize the new dict with the old dict's atoms table. Accept the new strtab from ctf_str_write_strtab. Adjust for addition of ctf_dynstrtab. * ctf-string.c (ctf_strraw_explicit): Improve comments. (ctf_str_create_atoms): Prepopulate from an existing atoms table, or alternatively pull in all strings from the strtab and turn them into atoms. (ctf_str_free_atoms): Free the dynstrtab and its strtab. (struct ctf_strtab_write_state): Remove. (ctf_str_count_strtab): Fold this... (ctf_str_populate_sorttab): ... and this... (ctf_str_write_strtab): ... into this. Prepend existing strings to the strtab rather than resorting them (and wrecking their offsets). Keep the dynstrtab updated. Update refs for all atoms with refs, whether or not they are strings newly added to the strtab.	2 years ago
Nick Alcock	149ce5c263	libctf: replace 'pending refs' abstraction A few years ago we introduced a 'pending refs' abstraction to fix one problem: serializing a dict, then changing it would tend to corrupt the dict because the strtab sort we do on strtab writeout (to improve compression efficiency) would modify the offset of any strings that sorted lexicographically earlier in the strtab: so we added a new restriction that all strings are added only at serialization time, and maintained a set of 'pending' refs that were added earlier, whose offsets we could update (like other refs) at writeout time. This was in hindsight seriously problematic for maintenance (because serialization has to traverse all strings in all datatypes in the entire dict), and has become impossible to sustain now that we can read in existing dicts, modify them, and reserialize them again. We really don't want to have to dig through the entire dict we jut read in just in order to dig out all its strtab offsets, then change it, just for the sake of a sort that adds a frankly trivial amount of compression efficiency. Sorting is still worthwhile -- but it sacrifices very little to only sort newly-added portions of the strtab, reusing older portions as necessary. As a first stage in this, discard the whole "pending refs" abstraction and replace it with "movable" refs, which are exactly like all other refs (addresses containing the strtab offset of some string, which are updated wiht the final strtab offset on serialization) except that we track them in a reverse dict so that we can move the refs around (which we do whenever we realloc() a buffer containing a bunch of structure members or something when we add members to the structure). libctf/ * ctf-create.c (ctf_add_enumerator): Call ctf_str_move_refs; add a movable ref. (ctf_add_member_offset): Likewise. * ctf-util.c (ctf_realloc): Delete. * ctf-serialize.c (ctf_serialize): No longer use it. Adjust to new fields. * ctf-string.c (ctf_str_purge_atom_refs): Purge movable refs. (ctf_str_free_atom): Free freeable atoms' strings. (ctf_str_create_atoms): Create the movable refs dynhash if needed. (ctf_str_free_atoms): Destroy it. (CTF_STR_MOVABLE): Switch (back) from ints to flags (see previous reversion). Add new flag. (aref_create): New, populate movable refs if need be. (ctf_str_add_ref_internal): Switch back to flags, update refs directly for nonprovisional strings (with already-known fixed offsets); create refs via aref_create. Allocate strings only if not within an mmapped strtab. (ctf_str_add_movable_ref): New. (ctf_str_add): Adjust to CTF_STR_* reintroduction. (ctf_str_add_external): LIkewise. (ctf_str_move_refs): New, move refs via ctf_str_movable_refs backpointer. (ctf_str_purge_refs): Drop ctf_str_num_refs. (ctf_str_update_refs): Fix indentation. * ctf-impl.h (struct ctf_str_atom_movable): New. (struct ctf_dict.ctf_str_num_refs): Drop. (struct ctf_dict.ctf_str_movable_refs): New. (ctf_str_add_movable_ref): Declare. (ctf_str_move_refs): Likewise. (ctf_realloc): Drop.	2 years ago
Nick Alcock	3301ddba1b	Revert "libctf: do not corrupt strings across ctf_serialize" This reverts commit `986e9e3aa0`. (We do not revert the testcase -- it remains valid -- but we are taking a different, less complex and more robust approach.) This also deletes the pending refs abstraction without (yet) replacing it, so some tests will fail for a commit or two.	2 years ago
Nick Alcock	629acbe4a3	libctf: rename ctf_dict.ctf_{symtab,strtab} These two fields are constantly confusing because CTF dicts contain both a symtypetab and strtab, but these fields are not that: they are the symtab and strtab from the ELF file. We have enough string tables now (internal, external, synthetic external, dynamic) that we need to at least name them better than this to avoid getting totally confused. Rename them to ctf_ext_symtab and ctf_ext_strtab. libctf/ * ctf-dump.c (ctf_dump_objts): Rename ctf_symtab -> ctf_ext_symtab. * ctf-impl.h (struct ctf_dict.ctf_symtab): Rename to... (struct ctf_dict.ctf_ext_strtab): ... this. (struct ctf_dict.ctf_strtab): Rename to... (struct ctf_dict.ctf_ext_strtab): ... this. * ctf-lookup.c (ctf_lookup_symbol_name): Adapt. (ctf_lookup_symbol_idx): Adapt. (ctf_lookup_by_sym_or_name): Adapt. * ctf-open.c (ctf_bufopen_internal): Adapt. (ctf_dict_close): Adapt. (ctf_getsymsect): Adapt. (ctf_getstrsect): Adapt. (ctf_symsect_endianness): Adapt.	2 years ago
Nick Alcock	bb2a9a465e	libctf: fix a comment typo ctf_update has been called ctf_serialize for years now. libctf/ * ctf-impl.h: Fix comment typo.	2 years ago
Nick Alcock	4fa4e3d92a	libctf: delete LCTF_DIRTY This flag was meant as an optimization to avoid reserializing dicts unnecessarily. It was critically necessary back when serialization was done by ctf_update() and you had to call that every time you wanted any new modifications to the type table to be usable by other types, but that has been unnecessary for years now, and serialization is only done once when writing out, which one would naturally assume would always serialize the dict. Worse, it never really worked: it only tracked newly-added types, not things like added symbols which might equally well require reserialization, and it gets in the way of an upcoming change. Delete entirely. libctf/ * ctf-create.c (ctf_create): Drop LCTF_DIRTY. (ctf_discard): Likewise. (ctf_rollback): Likewise. (ctf_add_generic): Likewise. (ctf_set_array): Likewise. (ctf_add_enumerator): Likewise. (ctf_add_member_offset): Likewise. (ctf_add_variable_forced): Likewise. * ctf-link.c (ctf_link_intern_extern_string): Likewise. (ctf_link_add_strtab): Likewise. * ctf-serialize.c (ctf_serialize): Likewise. * ctf-impl.h (LCTF_DIRTY): Likewise. (LCTF_LINKING): Renumber.	2 years ago
Nick Alcock	b4b77b26e2	libctf: fix a comment A mistaken "not" in ctf_err_warn made it seem like we only extracted error messages if this was not an error. libctf/ * ctf-subr.c (ctf_err_warn): Fix comment.	2 years ago
Nick Alcock	8a60c93096	libctf: support addition of types to dicts read via ctf_open() libctf has long declared deserialized dictionaries (out of files or ELF sections or memory buffers or whatever) to be read-only: back in the furthest prehistory this was not the case, in that you could add a few sorts of type to such dicts, but attempting to do so often caused horrible memory corruption, so I banned the lot. But it turns out real consumers want it (notably DTrace, which synthesises pointers to types that don't have them and adds them to the ctf_open()ed dicts if it needs them). Let's bring it back again, but without the memory corruption and without the massive code duplication required in days of yore to distinguish between static and dynamic types: the representation of both types has been identical for a few years, with the only difference being that types as a whole are stored in a big buffer for types read in via ctf_open and per-type hashtables for newly-added types. So we discard the internally-visible concept of "readonly dictionaries" in favour of declaring the range of types that were already present when the dict was read in to be read-only: you can't modify them (say, by adding members to them if they're structs, or calling ctf_set_array on them), but you can add more types and point to them. (The API remains the same, with calls sometimes returning ECTF_RDONLY, but now they do so less often.) This is a fairly invasive change, mostly because code written since the ban was introduced didn't take the possibility of a static/dynamic split into account. Some of these irregularities were hard to define as anything but bugs. Notably: - The symbol handling was assuming that symbols only needed to be looked for in dynamic hashtabs or static linker-laid-out indexed/ nonindexed layouts, but now we want to check both in case people added more symbols to a dict they opened. - The code that handles type additions wasn't checking to see if types with the same name existed at all (so you could do ctf_add_typedef (fp, "foo", bar) repeatedly without error). This seems reasonable for types you just added, but we probably do want to ban addition of types with names that override names we already used in the ctf_open()ed portion, since that would probably corrupt existing type relationships. (Doing things this way also avoids causing new errors for any existing code that was doing this sort of thing.) - ctf_lookup_variable entirely failed to work for variables just added by ctf_add_variable: you had to write the dict out and read it back in again before they appeared. - The symbol handling remembered what symbols you looked up but didn't remember their types, so you could look up an object symbol and then find it popping up when you asked for function symbols, which seems less than ideal. Since we had to rejig things enough to be able to distinguish function and object symbols internally anyway (in order to give suitable errors if you try to add a symbol with a name that already existed in the ctf_open()ed dict), this bug suddenly became more visible and was easily fixed. We do not (yet) support writing out dicts that have been previously read in via ctf_open() or other deserializer (you can look things up in them, but not write them out a second time). This never worked, so there is no incompatibility; if it is needed at a later date, the serializer is a little bit closer to having it work now (the only table we don't deal with is the types table, and that's because the upcoming CTFv4 changes are likely to make major changes to the way that table is represented internally, so adding more code that depends on its current form seems like a bad idea). There is a new testcase that tests much of this, in particular that modification of existing types is still banned and that you can add new ones and chase them without error. libctf/ * ctf-impl.h (struct ctf_dict.ctf_symhash): Split into... (ctf_dict.ctf_symhash_func): ... this and... (ctf_dict.ctf_symhash_objt): ... this. (ctf_dict.ctf_stypes): New, counts static types. (LCTF_INDEX_TO_TYPEPTR): Use it instead of CTF_RDWR. (LCTF_RDWR): Deleted. (LCTF_DIRTY): Renumbered. (LCTF_LINKING): Likewise. (ctf_lookup_variable_here): New. (ctf_lookup_by_sym_or_name): Likewise. (ctf_symbol_next_static): Likewise. (ctf_add_variable_forced): Likewise. (ctf_add_funcobjt_sym_forced): Likewise. (ctf_simple_open_internal): Adjust. (ctf_bufopen_internal): Likewise. * ctf-create.c (ctf_grow_ptrtab): Adjust a lot to start with. (ctf_create): Migrate a bunch of initializations into bufopen. Force recreation of name tables. Do not forcibly override the model, let ctf_bufopen do it. (ctf_static_type): New. (ctf_update): Drop LCTF_RDWR check. (ctf_dynamic_type): Likewise. (ctf_add_function): Likewise. (ctf_add_type_internal): Likewise. (ctf_rollback): Check ctf_stypes, not LCTF_RDWR. (ctf_set_array): Likewise. (ctf_add_struct_sized): Likewise. (ctf_add_union_sized): Likewise. (ctf_add_enum): Likewise. (ctf_add_enumerator): Likewise (only on the target dict). (ctf_add_member_offset): Likewise. (ctf_add_generic): Drop LCTF_RDWR check. Ban addition of types with colliding names. (ctf_add_forward): Note safety under the new rules. (ctf_add_variable): Split all but the existence check into... (ctf_add_variable_forced): ... this new function. (ctf_add_funcobjt_sym): Likewise... (ctf_add_funcobjt_sym_forced): ... for this new function. * ctf-link.c (ctf_link_add_linker_symbol): Ban calling on dicts with any stypes. (ctf_link_add_strtab): Likewise. (ctf_link_shuffle_syms): Likewise. (ctf_link_intern_extern_string): Note pre-existing prohibition. * ctf-lookup.c (ctf_lookup_by_id): Drop LCTF_RDWR check. (ctf_lookup_variable): Split out looking in a dict but not its parent into... (ctf_lookup_variable_here): ... this new function. (ctf_lookup_symbol_idx): Track whether looking up a function or object: cache them separately. (ctf_symbol_next): Split out looking in non-dynamic symtypetab entries to... (ctf_symbol_next_static): ... this new function. Don't get confused by the simultaneous presence of static and dynamic symtypetab entries. (ctf_try_lookup_indexed): Don't waste time looking up symbols by index before there can be any idea how symbols are numbered. (ctf_lookup_by_sym_or_name): Distinguish between function and data object lookups. Drop LCTF_RDWR. (ctf_lookup_by_symbol): Adjust. (ctf_lookup_by_symbol_name): Likewise. * ctf-open.c (init_types): Rename to... (init_static_types): ... this. Drop LCTF_RDWR. Populate ctf_stypes. (ctf_simple_open): Drop writable arg. (ctf_simple_open_internal): Likewise. (ctf_bufopen): Likewise. (ctf_bufopen_internal): Populate fields only used for writable dicts. Drop LCTF_RDWR. (ctf_dict_close): Cater for symhash cache split. * ctf-serialize.c (ctf_serialize): Use ctf_stypes, not LCTF_RDWR. * ctf-types.c (ctf_variable_next): Drop LCTF_RDWR. * testsuite/libctf-lookup/add-to-opened*: New test.	2 years ago
Nick Alcock	2ba5ec13b2	libctf: fix name lookup in dicts containing base-type bitfields The intent of the name lookup code was for lookups to yield non-bitfield basic types except if none existed with a given name, and only then return bitfield types with that name. Unfortunately, the code as written only does this if the base type has a type ID higher than all bitfield types, which is most unlikely (the opposite is almost always the case). Adjust it so that what ends up in the name table is the highest-width zero-offset type with a given name, if any such exist, and failing that the first type with that name we see, no matter its offset. (We don't define which bitfield type you get, after all, so we might as well just stuff in the first we find.) Reported by Stephen Brennan <stephen.brennan@oracle.com>. libctf/ * ctf-open.c (init_types): Modify to allow some lookups during open; detect bitfield name reuse and prefer less bitfieldy types. * testsuite/libctf-writable/libctf-bitfield-name-lookup.*: New test.	2 years ago
Nick Alcock	54a0219150	libctf: remove static/dynamic name lookup distinction libctf internally maintains a set of hash tables for type name lookups, one for each valid C type namespace (struct, union, enum, and everything else). Or, rather, it maintains two sets of hash tables: one, a ctf_hash , is meant for lookups in ctf_(buf)open()ed dicts with fixed content; the other, a ctf_dynhash , is meant for lookups in ctf_create()d dicts. This distinction was somewhat valuable in the far pre-binutils past when two different hashtable implementations were used (one expanding, the other fixed-size), but those days are long gone: the hash table implementations are almost identical, both wrappers around the libiberty hashtab. The ctf_dynhash has many more capabilities than the ctf_hash (iteration, deletion, etc etc) and has no downsides other than starting at a fixed, arbitrary small size. That limitation is easy to lift (via a new ctf_dynhash_create_sized()), following which we can throw away nearly all the ctf_hash implementation, and all the code to choose between readable and writable hashtabs; the few convenience functions that are still useful (for insertion of name -> type mappings) can also be generalized a bit so that the extra string verification they do is potentially available to other string lookups as well. (libctf still has two hashtable implementations, ctf_dynhash, above, and ctf_dynset, which is a key-only hashtab that can avoid a great many malloc()s, used for high-volume applications in the deduplicator.) libctf/ * ctf-create.c (ctf_create): Eliminate ctn_writable. (ctf_dtd_insert): Likewise. (ctf_dtd_delete): Likewise. (ctf_rollback): Likewise. (ctf_name_table): Eliminate ctf_names_t. * ctf-hash.c (ctf_dynhash_create): Comment update. Reimplement in terms of... (ctf_dynhash_create_sized): ... this new function. (ctf_hash_create): Remove. (ctf_hash_size): Remove. (ctf_hash_define_type): Remove. (ctf_hash_destroy): Remove. (ctf_hash_lookup_type): Rename to... (ctf_dynhash_lookup_type): ... this. (ctf_hash_insert_type): Rename to... (ctf_dynhash_insert_type): ... this, moving validation to... * ctf-string.c (ctf_strptr_validate): ... this new function. * ctf-impl.h (struct ctf_names): Extirpate. (struct ctf_lookup.ctl_hash): Now a ctf_dynhash_t. (struct ctf_dict): All ctf_names_t fields are now ctf_dynhash_t. (ctf_name_table): Now returns a ctf_dynhash_t. (ctf_lookup_by_rawhash): Remove. (ctf_hash_create): Likewise. (ctf_hash_insert_type): Likewise. (ctf_hash_define_type): Likewise. (ctf_hash_lookup_type): Likewise. (ctf_hash_size): Likewise. (ctf_hash_destroy): Likewise. (ctf_dynhash_create_sized): New. (ctf_dynhash_insert_type): New. (ctf_dynhash_lookup_type): New. (ctf_strptr_validate): New. * ctf-lookup.c (ctf_lookup_by_name_internal): Adapt. * ctf-open.c (init_types): Adapt. (ctf_set_ctl_hashes): Adapt. (ctf_dict_close): Adapt. * ctf-serialize.c (ctf_serialize): Adapt. * ctf-types.c (ctf_lookup_by_rawhash): Remove.	2 years ago
Nick Alcock	ca01922784	libctf: don't leak the symbol name in the name->type cache This cache replaced a cache of symbol index->ctf_id_t. That cache was just an array, so it could get away with just being free()d, but the ctfi_symnamedicts cache that replaced it is a full dynhash with a dynamically-allocated string as the key. As such, it needs freeing with ctf_dynhash_destroy(), not just free(), or we leak parts of the underlying hashtab, and all the keys. libctf/ChangeLog: * ctf-archive.c (ctf_arc_flush_caches): Fix leak.	2 years ago
Nick Alcock	6364617120	binutils, objdump: Add --ctf-parent-section This lets you examine CTF where the parent and child dicts are in entirely different sections, rather than in a CTF archive with members with different names. The linker doesn't emit ELF objects structured like this, but some third-party linkers may; it's also useful for objcopy-constructed files in some cases. (This is what the objdump --ctf-parent option used to do before commit `80b56fad5c` in 2021. The new semantics of that option are much more useful, but that doesn't mean the old ones are never useful at all, so let's bring them back.) (I was specifically driven to add this by DTrace's obscure "ctypes" and "dtypes" options, which dump its internal, dynamically-generated dicts out to files for debugging purposes: there are two, one the parent of the other. Since they're in two separate files rather than a CTF archive and we have no tools that paste files together into archives, objdump wouldn't show them -- and even pasting them together into an ELF executable with objcopy didn't help, since objdump had no options that could be used to look in specific sections for the parent dict. With --ctf-parent-section, this sort of obscure use case becomes possible again. You'll never need it for the output of the normal linker.) binutils/ * doc/ctf.options.texi: Add --ctf-parent-section=. * objdump.c (dump_ctf): Implement it. (dump_bfd): Likewise. (main): Likewise.	3 years ago
Gustavo Romero	0e6747d2a6	gdb: Document qIsAddressTagged packet This commit documents the qIsAddressTagged packet. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Eli Zaretskii <eliz@gnu.org> Approved-By: Eli Zaretskii <eliz@gnu.org>	2 years ago
Gustavo Romero	648a8c6168	gdb/testsuite: Add unit tests for qIsAddressTagged packet Add unit tests for testing qIsAddressTagged packet request creation and reply checks. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>	2 years ago
Gustavo Romero	c040e0b107	gdb: Add qIsAddressTagged packet This commit adds a new packet, qIsAddressTagged, allowing GDB remote targets to use it to query the stub if a given address is tagged. Currently, the memory tagging address check is done via a read query, where the contents of /proc/<PID>/smaps is read and the flags are inspected for memory tagging-related flags that indicate the address is in a memory tagged region. This is not ideal, for example, for QEMU stub and other cases, such as on bare-metal, where there is no notion of an OS file like 'smaps.' Hence, the introduction of qIsAddressTagged packet allows checking if an address is tagged in an agnostic way. The is_address_tagged target hook in remote.c attempts to use the qIsAddressTagged packet first for checking if an address is tagged and if the stub does not support such a packet (reply is empty) it falls back to using the current mechanism that reads the contents of /proc/<PID>/smaps via vFile requests. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>	2 years ago
Gustavo Romero	7202f41f5f	gdb: Introduce is_address_tagged target hook This commit introduces a new target hook, target_is_address_tagged, which is used instead of the gdbarch_tagged_address_p gdbarch hook in the upper layer (printcmd.c). This change enables easy specialization of memory tagging address check per target in the future. As target_is_address_tagged continues to utilize the gdbarch_tagged_address_p hook, there is no change in behavior for all the targets that use the new target hook (i.e., the remote.c, aarch64-linux-nat.c, and corelow.c targets). Just the gdbarch_tagged_address_p signature is changed for convenience, since target_is_address_tagged takes the address to be checked as a CORE_ADDR type. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>	2 years ago
Gustavo Romero	a0e28bb151	gdb: Use passed gdbarch instead of calling current_inferior In do_examine function, use passed gdbarch when checking if an address is tagged instead of calling current_inferior()->arch() to make the code more localized and help modularity by not calling a current_* function, which disguises the use of a global state/variable. There is no change in the code behavior. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Suggested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>	2 years ago
Gustavo Romero	681ad8174d	gdb: aarch64: Remove MTE address checking from memtag_matches_p This commit removes aarch64_linux_tagged_address_p from aarch64_linux_memtag_matches_p. aarch64_linux_tagged_address_p checks if an address is tagged (MTE) or not. The check is redundant because aarch64_linux_memtag_matches_p is always called from the upper layers (i.e. from printcmd.c via gdbarch hook gdbarch_memtag_matches_p) after either gdbarch_tagged_address_p (that already points to aarch64_linux_tagged_address_p) has been called or after should_validate_memtags (that calls gdbarch_tagged_address_p at the end) has been called, so the address is already checked. Hence: a) in print_command_1, gdbarch_memtag_matches_p is called only after should_validate_memtags is called, which checks the address at its end; b) in memory_tag_check_command, gdbarch_memtag_matches_p is called only after gdbarch_tagged_address_p is called directly. Also, because after this change the address checking only happens at the upper layer it now allows the address checking to be specialized easily per target, via a target hook. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>	2 years ago
Gustavo Romero	f00fb5e1d1	gdb: aarch64: Move MTE address check out of set_memtag Remove check in parse_set_allocation_tag_input as it is redundant: currently the check happens at the end of parse_set_allocation_tag_input and also in set_memtag (called after parse_set_allocation_tag_input). After it, move MTE address check out of set_memtag and add this check to the upper layer, before set_memtag is called. This is a preparation for using a target hook instead of a gdbarch hook on MTE address checks. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com>	2 years ago
Gustavo Romero	75606e5e8d	gdb: aarch64: Remove MTE address checking from get_memtag This commit removes aarch64_linux_tagged_address_p from aarch64_linux_get_memtag. aarch64_linux_tagged_address_p checks if an address is tagged (MTE) or not. The check is redundant because aarch64_linux_get_memtag is always called from the upper layers (i.e. from printcmd.c via gdbarch hook gdbarch_get_memtag) after either gdbarch_tagged_address_p (that already points to aarch64_linux_tagged_address_p) has been called or after should_validate_memtags (that calls gdbarch_tagged_address_p at the end) has been called, so the address is already checked. Hence: a) in print_command_1, aarch64_linux_get_memtag (via gdbarch_get_memtag hook) is called but only after should_validate_memtags, which calls gdbarch_tagged_address_p; b) in do_examine, aarch64_linux_get_memtag is also called only after gdbarch_tagged_address_p is directly called; c) in memory_tag_check_command, gdbarch_get_memtag is called -- tags matching or not -- after the initial check via direct call to gdbarch_tagged_address_p; d) in memory_tag_print_tag_command, address is checked directly via gdbarch_tagged_address_p before gdbarch_get_memtag is called. Also, because after this change the address checking only happens at the upper layer it now allows the address checking to be specialized easily per target, via a target hook. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>	2 years ago
Alan Modra	9cf3c87e16	Re: elf: Strip unreferenced weak undefined symbols PR ld/31652 * elflink.c (_bfd_elf_link_output_relocs): Don't segfault on NULL rel_hash.	2 years ago
H.J. Lu	eebad48efe	elf: Strip unreferenced weak undefined symbols Linker will resolve an undefined symbol only if it is referenced by relocation. Unreferenced weak undefined symbols serve no purpose. Weak undefined symbols appear in the dynamic symbol table only when they are referenced by dynamic relocation. Mark symbols with relocation and strip undefined weak symbols if they don't have relocation and aren't in the dynamic symbol table. bfd/ PR ld/31652 * elf-bfd.h (elf_link_hash_entry): Add has_reloc. * elf-vxworks.c (elf_vxworks_emit_relocs): Set has_reloc. * elflink.c (_bfd_elf_link_output_relocs): Likewise. (elf_link_output_extsym): Strip undefined weak symbols if they don't have relocation and aren't in the dynamic symbol table. ld/ PR ld/31652 * testsuite/ld-elf/elf.exp: Run undefweak tests. * testsuite/ld-elf/undefweak-1.rd: New file. * testsuite/ld-elf/undefweak-1a.s: Likewise. * testsuite/ld-elf/undefweak-1b.s: Likewise. * testsuite/ld-x86-64/weakundef-1.nd: Likewise. * testsuite/ld-x86-64/weakundef-1a.s: Likewise. * testsuite/ld-x86-64/weakundef-1b.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run undefweak tests.	2 years ago
Alan Modra	2304772225	memory leak in bfd/dwarf2.c * dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free dwarf_addr_buffer and dwarf_str_offsets_buffer.	2 years ago
Alan Modra	a1defbe426	mmix disassemble memory leak It's a once-off and of no consequence, but fix it anyway. The mmix caonoicalize_syms array is an array of pointers. Freeing it won't lose symbol names. * mmix-dis.c (initialize_mmix_dis_info): Free syms.	2 years ago
GDB Administrator	eae4098321	Automatic date update in version.in	2 years ago
Tom de Vries	4c8fc16756	[gdb/testsuite] Use find_gnatmake instead of gdb_find_gnatmake On SLE-11, with an older dejagnu version, I ran into: ... Running gdb.ada/mi_prot.exp ... UNRESOLVED: gdb.ada/mi_prot.exp: \ testcase aborted due to invalid command name: gdb_find_gnatmake ERROR: tcl error sourcing gdb.ada/mi_prot.exp. ERROR: invalid command name "gdb_find_gnatmake" while executing "::gdb_tcl_unknown gdb_find_gnatmake" ("uplevel" body line 1) invoked from within "uplevel 1 ::gdb_tcl_unknown $args" (procedure "::unknown" line 5) invoked from within "gdb_find_gnatmake" (procedure "gnatmake_version_at_least" line 2) invoked from within ... Proc gdb_find_gnatmake is actually a backup for find_gnatmake: ... if {[info procs find_gnatmake] == ""} { rename gdb_find_gnatmake find_gnatmake ... so gnatmake_version_at_least should use find_gnatmake instead. For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we don't run into this error. For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to find_gnatmake, and we do run into the error. It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it seems something legitimate to use. Maybe we should use future_ or gdb_future_ prefix instead to make this more clear, but I've left that alone for now. Fix this by: - triggering the same error with a recent dejagnu by removing gdb_find_gnatmake unless used (and likewise for other procs in future.exp), and - using find_gnatmake in gnatmake_version_at_least. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31647 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647	2 years ago
Tom de Vries	b0c431de3f	[gdb/testsuite] Use allocator_may_return_null=1 in two test-cases Simon reported [1] that recent commit `06e967dbc9` ("[gdb/python] Throw MemoryError in inferior.read_memory if malloc fails") introduced AddressSanitizer allocation-size-too-big errors in the two test-cases affected by this commit. Fix this by suppressing the error in the two test-cases using allocator_may_return_null=1. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html	2 years ago
Simon Marchi	523e454fab	gdbsupport: constify some return values in print-utils.{h,cc} There is no reason the callers of these functions need to change the returned string, so change the `char ` return types to `const char `. Update a few callers to also use `const char *`. Change-Id: I94adff574d5e1b326e8cc688cf1817a15b408b96 Approved-By: Tom Tromey <tom@tromey.com>	2 years ago
Nick Clifton	31d5afc19d	HPPA64 linker: Do not force the generation of DT_FLAGS for Linux targets. PR 30743	2 years ago
Will Hawkins	41d5ff24c6	Add DW_TAG_compile_unit DIE to Dummy CUs Dummy CUs help detect errors and are very helpful. However, the DWARF spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to the header. This patch adds that. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650 Signed-off-by: Will Hawkins <hawkinsw@obs.cr> Approved-By: Tom de Vries <tdevries@suse.de> Tested-By: Tom de Vries <tdevries@suse.de>	2 years ago
Alan Modra	ebf1867135	Re: Fix address violations when reading corrupt VMS records Fixes error reports about the length of EEOM records produced by gas. PR 21618 * vms-alpha.c (evax_bfd_print_emh): Don't read subtyp if short record. Consolidate error messages. (evax_bfd_print_eeom): Allow length 10 record.	2 years ago
Alan Modra	ee19a4725c	alpha_vms_get_section_contents vs. fuzzed files This patch is in response to an oss-fuzz report regarding use-of-uninitialized-value in bfd_is_section_compressed_info from section contents provided by alpha_vms_get_section_contents. That hole is covered by using bfd_zalloc rather than bfd_alloc. The rest of the patch is mostly a tidy. In a function returning section contents, I tend to prefer a test on the section properties over a test on file properties. That's why I've changed the file flags test to one on section filepos and flags before calling _bfd_generic_get_section_contents. Also, fuzzed objects can easily have sections with file backing in relocatable objects, or sections without file backing in images. Possible confusion is avoided by testing each section. Note that we are always going to run into out-of-memory with fuzzed alpha-vms object files due to sections with contents via ETIR records. eg. ETIR__C_STO_IMMR stores a number of bytes repeatedly, with a 32-bit repeat count. So section contents can be very large from a relatively small file. I'm inclined to think that an out-of-memory error is fine for such files. * vms-alpha.c (alpha_vms_get_section_contents): Handle sections with non-zero filepos or without SEC_HAS_CONTENTS via _bfd_generic_get_section_contents. Zero memory allocated for sections filled by ETIR records.	2 years ago
Alan Modra	170957ff9b	Tidy objdump opb expressions I don't think any of these can overflow, but since all of the expressions I'm editing here are inside a while loop with condition addr_offset < stop_offset, this change makes it more obvious that they can't overflow. * objdump.c (disassemble_bytes): Calculate octet expressions involving both addr_offset and stop_offset by first subtracting addr_offset from stop_offset.	2 years ago

1 2 3 4 5 ...

118422 Commits (cb5dfff88ea6ed73b0222cfeeef97dc6d4ccf84f) All Branches Search

118422 Commits (cb5dfff88ea6ed73b0222cfeeef97dc6d4ccf84f)

All Branches