aboutsummaryrefslogtreecommitdiff
path: root/gdb/linespec.c
AgeCommit message (Collapse)AuthorFilesLines
2023-12-13Use unique_xmalloc_ptr in explicit_location_specTom Tromey1-33/+40
This changes explicit_location_spec to use unique_xmalloc_ptr, removing some manual memory management. Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-13Use unique_xmalloc_ptr in linespec_location_specTom Tromey1-1/+2
This changes linespec_location_spec to use unique_xmalloc_ptr, removing some manual memory management. Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-05Fix breakpoints on symbols with multiple trampoline symbolsHannes Domani1-0/+4
On mingw targets it's possible that there are multiple trampoline symbols for __cxa_throw, in each module where a throw is done, but without a corresponding global symbol. Since commit 77f2120b200be6cabbf6f610942fc1173a8df6d3 they cancel each other out in search_minsyms_for_name, which makes it impossible to set a breakpoint there: (gdb) b __cxa_throw Function "__cxa_throw" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (__cxa_throw) pending. (gdb) c Continuing. [Inferior 1 (process 10004) exited with code 03] With catch throw it also doesn't work, and you don't even get an error message: (gdb) catch throw Catchpoint 2 (throw) (gdb) c Continuing. [Inferior 1 (process 5532) exited with code 03] (gdb) The fix is to simply ignore other trampoline symbols when looking for corresponding global symbols, and it's working as expected: (gdb) b __cxa_throw Breakpoint 2 at 0x13f091590 (2 locations) (gdb) c Continuing. Breakpoint 2.1, 0x000000013f091590 in __cxa_throw () (gdb) And catch throw also works again: (gdb) catch throw Catchpoint 2 (throw) (gdb) c Continuing. Catchpoint 2.1 (exception thrown), 0x000000013f181590 in __cxa_throw () (gdb) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29548 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31Add symbol::matches methodTom Tromey1-2/+1
This adds symbol::matches, a wrapper for symbol_matches_domain. Most places calling symbol_matches_domain can call this method instead, which is a bit less wordy and also (IMO) clearer. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-17gdb: add inferior-specific breakpointsAndrew Burgess1-2/+2
This commit extends the breakpoint mechanism to allow for inferior specific breakpoints (but not watchpoints in this commit). As GDB gains better support for multiple connections, and so for running multiple (possibly unrelated) inferiors, then it is not hard to imagine that a user might wish to create breakpoints that apply to any thread in a single inferior. To achieve this currently, the user would need to create a condition possibly making use of the $_inferior convenience variable, which, though functional, isn't the most user friendly. This commit adds a new 'inferior' keyword that allows for the creation of inferior specific breakpoints. Inferior specific breakpoints are automatically deleted when the associated inferior is removed from GDB, this is similar to how thread-specific breakpoints are deleted when the associated thread is deleted. Watchpoints are already per-program-space, which in most cases mean watchpoints are already inferior specific. There is a small window where inferior-specific watchpoints might make sense, which is after a vfork, when two processes are sharing the same address space. However, I'm leaving that as an exercise for another day. For now, attempting to use the inferior keyword with a watchpoint will give an error, like this: (gdb) watch a8 inferior 1 Cannot use 'inferior' keyword with watchpoints A final note on the implementation: currently, inferior specific breakpoints, like thread-specific breakpoints, are inserted into every inferior, GDB then checks once the inferior stops if we are in the correct thread or inferior, and resumes automatically if we stopped in the wrong thread/inferior. An obvious optimisation here is to only insert breakpoint locations into the specific program space (which mostly means inferior) that contains either the inferior or thread we are interested in. This would reduce the number times GDB has to stop and then resume again in a multi-inferior setup. I have a series on the mailing list[1] that implements this optimisation for thread-specific breakpoints. Once this series has landed I'll update that series to also handle inferior specific breakpoints in the same way. For now, inferior specific breakpoints are just slightly less optimal, but this is no different to thread-specific breakpoints in a multi-inferior debug session, so I don't see this as a huge problem. [1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
2023-08-16gdb, infcmd: support jump command in multi-inferior casePuputti, Matti1-1/+2
Fixes the issue where jump failed if multiple inferiors run the same source. See the below example $ gdb -q ./simple Reading symbols from ./simple... (gdb) break 2 Breakpoint 1 at 0x114e: file simple.c, line 2. (gdb) run Starting program: /temp/simple Breakpoint 1, main () at simple.c:2 2 int a = 42; (gdb) add-inferior [New inferior 2] Added inferior 2 on connection 1 (native) (gdb) inferior 2 [Switching to inferior 2 [<null>] (<noexec>)] (gdb) info inferiors Num Description Connection Executable 1 process 6250 1 (native) /temp/simple * 2 <null> 1 (native) (gdb) file ./simple Reading symbols from ./simple... (gdb) run Starting program: /temp/simple Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2 2 int a = 42; (gdb) info inferiors Num Description Connection Executable 1 process 6250 1 (native) /temp/simple * 2 process 6705 1 (native) /temp/simple (gdb) jump 3 Unreasonable jump request (gdb) In this example, jump fails because the debugger finds two different locations, one for each inferior. Solution is to limit the search to the current program space. This is done by having the jump_command function use decode_line_with_current_source rather than decode_line_with_last_displayed, which makes sense, the *_current_source function always looks up a location based on the current thread's location -- if a user is asking the current thread to jump, then surely their destination should be relative to where the current thread is located. Then, inside decode_line_with_current_source, the call to decode_line_1 is updated to pass through the current program_space, which will limit the returned locations to those in the current program space. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-03-11Constify linetablesTom Tromey1-3/+3
Linetables no longer change after they are created. This patch applies const to them. Note there is one hack to cast away const in mdebugread.c. This code allocates a linetable using 'malloc', then later copies it to the obstack. While this could be cleaned up, I chose not to do so because I have no way of testing it. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-19Remove ALL_BLOCK_SYMBOLSTom Tromey1-3/+1
This removes ALL_BLOCK_SYMBOLS in favor of foreach.
2023-02-19Convert block_containing_function to methodTom Tromey1-1/+1
This converts block_containing_function to be a method. This was mostly written by script.
2023-02-13Turn value_type into methodTom Tromey1-1/+1
This changes value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-09gdb/linespec.c: Fix missing source file during breakpoint re-setAaron Merey1-2/+2
During breakpoint re-setting, the source_filename of an explicit_location_spec is used to lookup the symtabs associated with the breakpoint being re-set. This source_filename is compared with each known symtab filename in order to retrieve the breakpoint's symtabs. However the source_filename may have been originally copied from a symtab's fullname (the path where GDB found the source file) when the breakpoint was first created. If a breakpoint symtab's filename and fullname differ and there is no substitute-path rule that converts the fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown during re-setting. Fix this by using a symtab's filename to set the explicit_location_spec source_filename instead of the symtab's fullname.
2023-01-09gdb/linespec.c: Fix -Wmaybe-uninitialized warningAaron Merey1-1/+1
Although the bool want_start_sal isn't actually used without being assigned a value, initialize it to be false in order to prevent the following -Wmaybe-uninitialized warning: linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’: linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized] 4150 | if (is_function && want_start_sal)
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-15gdb: remove static buffer in command_line_inputSimon Marchi1-1/+3
[I sent this earlier today, but I don't see it in the archives. Resending it through a different computer / SMTP.] The use of the static buffer in command_line_input is becoming problematic, as explained here [1]. In short, with this patch [2] that attempt to fix a post-hook bug, when running gdb.base/commands.exp, we hit a case where we read a "define" command line from a script file using command_command_line_input. The command line is stored in command_line_input's static buffer. Inside the define command's execution, we read the lines inside the define using command_line_input, which overwrites the define command, in command_line_input's static buffer. After the execution of the define command, execute_command does a command look up to see if a post-hook is registered. For that, it uses a now stale pointer that used to point to the define command, in the static buffer, causing a use-after-free. Note that the pointer in execute_command points to the dynamically-allocated buffer help by the static buffer in command_line_input, not to the static object itself, hence why we see a use-after-free. Fix that by removing the static buffer. I initially changed command_line_input and other related functions to return an std::string, which is the obvious but naive solution. The thing is that some callees don't need to return an allocated string, so this this an unnecessary pessimization. I changed it to passing in a reference to an std::string buffer, which the callee can use if it needs to return dynamically-allocated content. It fills the buffer and returns a pointers to the C string inside. The callees that don't need to return dynamically-allocated content simply don't use it. So, it started with modifying command_line_input as described above, all the other changes derive directly from that. One slightly shady thing is in handle_line_of_input, where we now pass a pointer to an std::string's internal buffer to readline's history_value function, which takes a `char *`. I'm pretty sure that this function does not modify the input string, because I was able to change it (with enough massaging) to take a `const char *`. A subtle change is that we now clear a UI's line buffer using a SCOPE_EXIT in command_line_handler, after executing the command. This was previously done by this line in handle_line_of_input: /* We have a complete command line now. Prepare for the next command, but leave ownership of memory to the buffer . */ cmd_line_buffer->used_size = 0; I think the new way is clearer. [1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/ [2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/ Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300 Reviewed-By: Tom Tromey <tom@tromey.com>
2022-06-17Fix GDB build with GCC 4.8 & 4.9Pedro Alves1-9/+14
With gcc 4.8/4.9, we run into this build failure (and other similar ones): /home/palves/gdb/binutils-gdb/src/gdb/location.h:224:59: error: could not convert ‘{0, LINE_OFFSET_UNKNOWN}’ from ‘<brace-enclosed initializer list>’ to ‘line_offset’ struct line_offset line_offset = {0, LINE_OFFSET_UNKNOWN}; ^ The issue is that at around the GCC 4.8/4.9 era, a default member initializer prevented the struct from being an aggregate, so you cannot use aggregate initialization on them. That rule changed after GCC 4.9 and GCC 5 & later uses new rules. Fix this by not using aggregate initialization for struct line_offset. The default member initization already leaves line_offset as {0, LINE_OFFSET_UNKNOWN}, so initialization to those values can just go away. The remaining cases are of the form {0, LINE_OFFSET_NONE}, and those cases can be better rewritten to delay setting the sign field until we know we have a valid offset. Change-Id: I0506ea4a83c5fa2f15e159569db68b3b0a7509b4
2022-06-17Convert set_location_spec_string to a methodPedro Alves1-1/+1
This converts set_location_spec_string to a method of location_spec, and makes the location_spec::as_string field protected, renaming it to m_as_string along the way. Change-Id: Iccfb1654e9fa7808d0512df89e775f9eacaeb9e0
2022-06-17Convert location_spec_to_string to a methodPedro Alves1-1/+1
This converts location_spec_to_string to a method of location_spec, simplifying the code using it, as it no longer has to use std::unique_ptr::get(). Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5
2022-06-17Convert location_spec_type to a methodPedro Alves1-1/+1
This converts location_spec_type to location_spec::type(). Change-Id: Iff4cbfafb1cf3d22adfa142ff939b4a148e52273
2022-06-17Eliminate copy_location_specPedro Alves1-2/+1
copy_location_spec is just a wrapper around location_spec::clone(), so remove it and call clone() directly. This simplifies users, as they no longer have to use std::unique_ptr::get(). Change-Id: I8ce8658589460b98888283b306b315a5b8f73976
2022-06-17Eliminate the two-level data structures behind location_specsPedro Alves1-59/+47
Currently, there's the location_spec hierarchy, and then some location_spec subclasses have their own struct type holding all their data fields. I.e., there is this: location_spec explicit_location_spec linespec_location_spec address_location_spec probe_location_spec and then these separate types: explicit_location linespec_location where: explicit_location_spec has-a explicit_location linespec_location_spec has-a linespec_location This patch eliminates explicit_location and linespec_location, inlining their members in the corresponding location_spec type. The location_spec subclasses were the ones currently defined in location.c, so they are moved to the header. Since the definitions of the classes are now visible, we no longer need location_spec_deleter. Some constructors that are used for cloning location_specs, like: explicit explicit_location_spec (const struct explicit_location *loc) ... were converted to proper copy ctors. In the process, initialize_explicit_location is eliminated, and some functions that returned the "data type behind a locspec", like get_linespec_location are converted to downcast functions, like as_linespec_location_spec. Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a
2022-06-17event_location -> location_specPedro Alves1-36/+36
Currently, GDB internally uses the term "location" for both the location specification the user input (linespec, explicit location, or an address location), and for actual resolved locations, like the breakpoint locations, or the result of decoding a location spec to SaLs. This is expecially confusing in the breakpoints module, as struct breakpoint has these two fields: breakpoint::location; breakpoint::loc; "location" is the location spec, and "loc" is the resolved locations. And then, we have a method called "locations()", which returns the resolved locations as range... The location spec type is presently called event_location: /* Location we used to set the breakpoint. */ event_location_up location; and it is described like this: /* The base class for all an event locations used to set a stop event in the inferior. */ struct event_location { and even that is incorrect... Location specs are used for finding actual locations in the program in scenarios that have nothing to do with stop events. E.g., "list" works with location specs. To clean all this confusion up, this patch renames "event_location" to "location_spec" throughout, and then all the variables that hold a location spec, they are renamed to include "spec" in their name, like e.g., "location" -> "locspec". Similarly, functions that work with location specs, and currently have just "location" in their name are renamed to include "spec" in their name too. Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
2022-04-28Remove "typedef enum ..."Tom Tromey1-2/+1
I noticed a few spots in GDB that use "typedef enum". However, in C++ this isn't as useful, as the tag is automatically entered as a typedef. This patch removes most uses of "typedef enum" -- the exceptions being in some nat-* code I can't compile, and glibc_thread_db.h, which I think is more or less a copy of some C code from elsewhere. Tested by rebuilding.
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi1-4/+3
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_ENTRY_PC macroSimon Marchi1-1/+1
Replace with equivalent method. Change-Id: I0e033095e7358799930775e61028b48246971a7d
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi1-2/+2
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi1-2/+2
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-20Replace symbol_symtab with symbol::symtabTom Tromey1-9/+9
This turns symbol_symtab into a method on symbol. It also replaces symbol_set_symtab with a method.
2022-04-11gdb: remove MSYMBOL_TYPE macroSimon Marchi1-7/+7
Add a getter and a setter for a minimal symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
2022-04-11gdb: remove symbol value macrosSimon Marchi1-7/+7
Remove all macros related to getting and setting some symbol value: #define SYMBOL_VALUE(symbol) (symbol)->value.ivalue #define SYMBOL_VALUE_ADDRESS(symbol) \ #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block #define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block #define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain #define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0) #define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \ #define BMSYMBOL_VALUE_ADDRESS(symbol) \ #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block Replace them with equivalent methods on the appropriate objects. Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
2022-04-07gdb: remove symtab::pspaceSimon Marchi1-20/+29
Same idea as previous patch, but for symtab::pspace. Change-Id: I1023abe622bea75ef648c6a97a01b53775d4104d
2022-04-07gdb: remove symtab::objfileSimon Marchi1-2/+2
Same idea as previous patch, but for symtab::objfile. I find it clearer without this wrapper, as it shows that the objfile is common to all symtabs of a given compunit. Otherwise, you could think that each symtab (of a given compunit) can have a specific objfile. Change-Id: Ifc0dbc7ec31a06eefa2787c921196949d5a6fcc6
2022-04-07gdb: remove symtab::blockvectorSimon Marchi1-5/+5
symtab::blockvector is a wrapper around compunit_symtab::blockvector. It is a bit misleadnig, as it gives the impression that a symtab has a blockvector. Remove it, change all users to fetch the blockvector through the compunit instead. Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
2022-02-24Move find_toplevel_char to cp-support.[ch]Keith Seitz1-77/+0
find_toplevel_char is being used more and more outside of linespec.c, so this patch moves it into cp-support.[ch].
2022-02-18Add constructor to bound_minimal_symbolTom Tromey1-2/+1
This adds a constructor to bound_minimal_symbol, to avoid a build failure with clang that Simon pointed out. I also took the opportunity to remove some redundant initializations, and to change one use of push_back to emplace_back, as suggested by Simon.
2022-02-06gdb: remove SYMBOL_LINE macroSimon Marchi1-3/+3
Add a getter and a setter for a symbol's line. Remove the corresponding macro and adjust all callers. Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi1-2/+2
Add a getter and a setter for a symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
2022-02-06gdb: remove SYMBOL_INLINED macroSimon Marchi1-1/+1
Add a getter and a setter for whether a symbol is inlined. Remove the corresponding macro and adjust all callers. Change-Id: I934468da3b5a32dd6b161a6f252a6b1b94737279
2022-02-06gdb: remove SYMBOL_DOMAIN macroSimon Marchi1-1/+1
Add a getter and a setter for a symbol's domain. Remove the corresponding macro and adjust all callers. Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi1-5/+5
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-02-06gdb: remove SYMTAB_PSPACE macroSimon Marchi1-20/+20
Remove the macro, replace with an equivalent method. Change-Id: Icccc20e7e8ae03ac4dac1c7514c25a12a9a0ac69
2022-02-06gdb: remove SYMTAB_OBJFILE macroSimon Marchi1-2/+2
Remove the macro, replace with an equivalent method. Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb
2022-02-06gdb: remove SYMTAB_BLOCKVECTOR macroSimon Marchi1-3/+3
Remove the macro, replace with an equivalent method. Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
2022-02-06gdb: remove SYMTAB_LANGUAGE macro, add getter/setterSimon Marchi1-1/+1
Add a getter and a setter for a symtab's language. Remove the corresponding macro and adjust all callers. Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
2022-02-06gdb: remove COMPUNIT_FILETABS macroSimon Marchi1-1/+1
I think that most remaining uses of COMPUNIT_FILETABS intend to get the primary filetab of the compunit_symtab specifically (and not to iterate over all filetabs, for example, those cases would use compunit_filetabs, which has been converted to compunit_symtab::filetabs), so replace mosts uses with compunit_symtab::primary_filetab. In jit.c, function finalize_symtab, we can save the symtab object returned by allocate_symtab and use it, it makes things simpler. Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38
2022-02-02gdb: add empty string check in parse_linespecAndrew Burgess1-7/+7
If parse_linespec (linespec.c) is passed ARG as an empty string then we end up calling `strchr (linespec_quote_characters, '\0')`, which will return a pointer to the '\0' at the end of linespec_quote_characters. This then results in GDB calling skip_quote_char with `ARG + 1`, which is undefined behaviour (as ARG only contained a single character, the '\0'). Fix this by checking for the first character of ARG being '\0' before the call to strchr. I have additionally added an assertion that ARG can't itself be nullptr, as calling is_ada_operator with nullptr can end up calling 'startswith' on the nullptr, which is undefined behaviour. Finally, I moved the declaration of TOKEN into the body of parse_linespec, to where TOKEN is defined. This patch came about while I was working on fixes for PR cli/28665 and PR gdb/28797. The actual fixes for these two issues will be in a later commit in this series, but, with this patch in place, both of the above bugs would hit the new assertion rather than accessing invalid memory and crashing. The '\0' check is not currently ever hit, but just makes the code a little safer. Because this patch only changes the nature of the failure for the above two bugs, there's no tests here. A later commit will fix the above two issues, at which point I'll add some tests. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797
2022-01-18Remove a use of xfree in location.cTom Tromey1-6/+2
This small cleanup removes a use of xfree from location.c, by switching to unique_xmalloc_ptr. One function is only used in location.c, so it is made static. And, another function is changed to avoid a copy.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-07gdb: make struct linespect contain vectors, not pointers to vectorsSimon Marchi1-117/+105
struct linespec contains pointers to vectors, instead of containing vectors directly. This is probably historical, when linespec_parser (which contains a struct linespec field) was not C++-ified yet. But it seems easy to change the pointers to vectors to just vectors today. This simplifies the code, we don't need to manually allocate and delete the vectors and there's no pointer that can be NULL. As far as I understand, there was not meaningful distinction between a NULL pointer to vector and an empty vector. So all NULL checks are changed for !empty checks. Change-Id: Ie759707da14d9d984169b93233343a86e2de9ee6
2021-12-07gdb/linespec.c: simplify conditionSimon Marchi1-2/+1
We can remove the empty check: if the vector has size 1, it is obviously not empty. This code ended up like this because the empty check used to be a NULL check. Change-Id: I1571bd0228818ca93f6a6b444e9b010dc2da4c08
2021-11-16gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptrAndrew Burgess1-2/+3
The motivation is to reduce the number of places where unmanaged pointers are returned from allocation type routines. All of the callers are updated. There should be no user visible changes after this commit.
generated by cgit v1.1 at 2024-11-19 12:49:14 +0000