aboutsummaryrefslogtreecommitdiff
path: root/gdb/buildsym.c
AgeCommit message (Collapse)AuthorFilesLines
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-07-29gdb: remove code to prepend comp dir in buildsym_compunit::start_subfileSimon Marchi1-25/+7
The bit of code removed by this patch was introduced to fix the same kind of problem that the previous patch fixes. That is, to try to match existing subfiles when different name forms are used to refer to a same file. The thread for the patch that introduced this code is: https://pi.simark.ca/gdb-patches/45F8CBDF.9090501@hq.tensilica.com/ The important bits are that the compiler produced a compilation unit with: DW_AT_name : test.c DW_AT_comp_dir : /home/maxim/W/BadgerPass/PR_14999 and DWARF v2 line table with: The Directory Table: /home/maxim/W/BadgerPass/PR_14999 The File Name Table: Entry Dir Time Size Name 1 1 1173897037 152 test.c Because the main symtab was created with only DW_AT_name, it was named "test.c". And because the path built from the line header contained the "directory" part, it was "/home/maxim/W/BadgerPass/PR_14999/test.c". Because of this mismatch, thing didn't work, so they added this code to prepend the compilation directory to the existing subfile names, so that this specific case would work. With the changes done earlier in this series, where subfiles are identified using the "most complete path possible", this case would be handled. The main subfile's would be "/home/maxim/W/BadgerPass/PR_14999/test.c" from the start (DW_AT_comp_dir + DW_AT_name). It's not so different from some DWARF 5 cases actually, which make the compilation directory explicit in the line table header. I therefore think that this code is no longer needed. It does feel like a quick hack to make one specific case work, and we have a more general solution now. Also, this code was introduced to work around a problem in the DWARF debug info or the DWARF debug info reader. In general, I think it's preferable for these hacks to be located in the specific debug info reader code, rather than in the common code. Even though this code was added to work around a DWARF reader problem, it's possible that some other debug info reader has started taking advantage of this code in the mean time. It's very difficult to know or verify, but I think the likelyhood is quite small, so I'm proposing to get rid of it to simplify things a little bit. Change-Id: I710b8ec0d449d1b110d67ddf9fcbdb2b37108306
2022-07-29gdb: add "id" fields to identify symtabs and subfilesSimon Marchi1-17/+19
Printing macros defined in the main source file doesn't work reliably using various toolchains, especially when DWARF 5 is used. For example, using the binaries produced by either of these commands: $ gcc --version gcc (GCC) 11.2.0 $ ld --version GNU ld (GNU Binutils) 2.38 $ gcc test.c -g3 -gdwarf-5 $ clang --version clang version 13.0.1 $ clang test.c -gdwarf-5 -fdebug-macro I get: $ ./gdb -nx -q --data-directory=data-directory a.out (gdb) start Temporary breakpoint 1 at 0x111d: file test.c, line 6. Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out Temporary breakpoint 1, main () at test.c:6 6 return ZERO; (gdb) p ZERO No symbol "ZERO" in current context. When starting to investigate this (taking the gcc-compiled binary as an example), we see that GDB fails to look up the appropriate macro scope when evaluating the expression. While stopped in macro_lookup_inclusion: (top-gdb) p name $1 = 0x62100011a980 "test.c" (top-gdb) p source.filename $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c" `source` is the macro_source_file that we would expect GDB to find. `name` comes from the symtab::filename field of the symtab we are stopped in. GDB doesn't find the appropriate macro_source_file because the name of the macro_source_file doesn't match exactly the name of the symtab. The name of the main symtab comes from the compilation unit's DW_AT_name, passed to the buildsym_compunit's constructor: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 The contents of DW_AT_name, in this case, is "test.c". It is typically (what I witnessed all compilers do) the same string that was passed to the compiler on the command-line. The name of the macro_source_file comes from the line number program header's file table, from the call to the line_header::file_file_name method: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 line_header::file_file_name prepends the directory path that the file entry refers to, in the file table (if the file name is not already absolute). In this case, the file name is "test.c", appended to the directory "/home/simark/build/binutils-gdb-one-target/gdb". Because the symtab's name is not created the same way as the macro_source_file's name is created, we get this mismatch. GDB fails to find the appropriate macro scope for the symtab, and we can't print macros when stopped in that symtab. To make this work, we must ensure that paths produced in these two ways end up identical. This can be tricky because of the different ways a path can be passed to the compiler by the user. Another thing to consider is that while the main symtab's name (or subfile, before it becomes a symtab) is created using DW_AT_name, the main symtab is also referred to using its entry in the line table header's file table, when processing the line table. We must therefore ensure that the same name is produced in both cases, so that a call to "start_subfile" for the main subfile will correctly find the already-created subfile, created by buildsym_compunit's constructor. If we fail to do that, things still often work, because of a fallback: the watch_main_source_file_lossage method. This method determines that if the main subfile has no symbols but there exists another subfile with the same basename (e.g. "test.c") that does have symbols, it's probably because there was some filename mismatch. So it replaces the main subfile with that other subfile. I think that heuristic is useful as a last effort to work around any bug or bad debug info, but I don't think we should design things such as to rely on it. It's a heuristic, it can get things wrong. So in my search for a fix, it is important that given some good debug info, we don't end up relying on that for things to work. A first attempt at fixing this was to try to prepend the compilation directory here or not prepend it there. In practice, because of all the possible combinations of debug info the compilers produce, it was not possible to get something that would produce reliable, consistent paths. Another attempt at fixing this was to make both macro_source_file objects and symtab objects use the most complete form of path possible. That means to prepend directories at least until we get an absolute path. In theory, we should end up with the same path in all cases. This generally worked, but because it changed the symtab names, it resulted in user-visible changes (for example, paths to source files in Breakpoint hit messages becoming always absolute). I didn't find this very good, first because there is a "set filename-display" setting that lets the user control how they want the paths to be displayed, and that would suddenly make this setting completely ineffective (although even today, it is a bit dependent on the debug info). Second, it would require a good amount of testsuite tweaks to make tests accept these suddenly absolute paths. This new patch is a slight variation of that: it adds a new field called "filename_for_id" in struct symtab and struct subfile, next to the existing filename field. The goal is to separate the internal ids used for finding objects from the names used for presentation. This field is used for identifying subfiles, symtabs and macro_source_files internally. For DWARF symtabs, this new field is meant to contain the "most complete possible" path, as discussed above. So for a given file, it must always be in the same form, everywhere. The existing symtab::filename field remains the one used for printing to the user, so there shouldn't be any change in how paths are printed. Changes in the core symtab files are: - Add "name_for_id" and "filename_for_id" fields to "struct subfile" and "struct symtab", next to existing "name" and "filename" fields. - Make buildsym_compunit::buildsym_compunit and buildsym_compunit::start_subfile accept a "name_for_id" parameter next to the existing "name" ones. - Make buildsym_compunit::start_subfile use "name_for_id" for looking up existing subfiles. This is the key thing for making calls to start_subfile for the main source file look up the existing subfile successfully, and avoid relying on watch_main_source_file_lossage. - Make sal_macro_scope pass "filename_for_id", rather than "filename", to macro_lookup_inclusion. This is the key thing to making the lookup work and macro printing work. Changes in the DWARF files are: - Make line_header::file_file_name return the "most complete possible" name. The only pre-existing user of this method is the macro code, to give the macro_source_file objects their name. And we now want them to have this "most complete possible" name, which will match the corresponding symtab's "filename_for_id". - Make dwarf2_cu::start_compunit_symtab pass the "most complete possible" name for the main symtab's "filename_for_id". In this context, where the info comes from the compilation unit's DW_AT_name / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if DW_AT_name is not already absolute. - Change dwarf2_start_subfile to build a name_for_id for the subfile being started. The simplest way is to re-use line_header::file_file_name, since the callers always have a file_entry handy. This ensures that it will get the exact same path representation as the macro code does, for the same file (since it also uses line_header::file_file_name). - Update calls to allocate_symtab to pass the "name_for_id" from the subfile. Tests exercising all this are added by the following patch. Of all the cases I tried, the only one I found that ends up relying on watch_main_source_file_lossage is the following one: $ clang --version clang version 13.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ clang ./test.c -g3 -O0 -gdwarf-4 $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out ... [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c) [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile As we can see, there are two forms used for "test.c", one with a "." and one without. This comes from the fact that the compilation unit DIE contains: DW_AT_name ("test.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") without a ".", and the line table for that file contains: include_directories[ 1] = "." file_names[ 1]: name: "test.c" dir_index: 1 When assembling the filename from that entry, we get a ".". It is a bit unexpected that the main filename resulting from the line table header does not match exactly the name in the compilation unit. For instance, gcc uses "./test.c" for the DW_AT_name, which gives identical paths in the compilation unit and in the line table header. Similarly, with DWARF 5: $ clang ./test.c -g3 -O0 -gdwarf-5 clang create two entries that refer to the same file but are of in a different form. include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb" include_directories[ 1] = "." file_names[ 0]: name: "test.c" dir_index: 0 file_names[ 1]: name: "test.c" dir_index: 1 The first file name produces a path without a "." while the second does. This is not caught by watch_main_source_file_lossage, because of dwarf_decode_lines that creates a symtab for each file entry in the line table. It therefore appears as "non-empty" to watch_main_source_file_lossage. This results in two symtabs: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x62100011aca0) debugformat DWARF 5 producer clang version 13.0.1 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000129ec0) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x62100011ad20) fullname (null) linetable ((struct linetable *) 0x0) } { symtab ./test.c ((struct symtab *) 0x62100011ad60) fullname (null) linetable ((struct linetable *) 0x621000129ef0) } } } I am not sure what is the consequence of this, but this is also what happens before my patch, so I think its acceptable to leave it as-is. To handle these two cases nicely, I think we will need a function that removes the unnecessary "." from path names, something that can be done later. Finally, I made a change in find_file_and_directory is necessary to avoid breaking test gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 Without that change, we would get: (gdb) info source Current source file is /dir/d/dw2-compdir-oldgcc42.S Compilation directory is /dir/d whereas the expected result is: (gdb) info source Current source file is dw2-compdir-oldgcc42.S Compilation directory is /dir/d This test was added here: https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html Long story short, GCC <= 4.2 apparently had a bug where it would generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S") and no DW_AT_comp_dir. The line table has one entry with filename "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0 normally refers to the compilation unit's comp dir, but it is non-existent in this case. This caused some symtab lookup problems, and to work around them, some workaround was added, which today reads as: if (res.get_comp_dir () == nullptr && producer_is_gcc_lt_4_3 (cu) && res.get_name () != nullptr && IS_ABSOLUTE_PATH (res.get_name ())) res.set_comp_dir (ldirname (res.get_name ())); Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432 It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no DW_AT_comp_dir and DW_AT_name is absolute. Prior to my patch, a subfile would get created with filename "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get created with filename "dw2-compdir-oldgcc42.S" from the line table's file table. Then watch_main_source_file_lossage would kick in and merge them, keeping only the "dw2-compdir-oldgcc42.S" one: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S) [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile And so "info source" would show "dw2-compdir-oldgcc42.S" as the filename. With my patch applied, but without the change in find_file_and_directory, both DW_AT_name and the line table would try to start a subfile with the same filename_for_id, and there was no need for watch_main_source_file_lossage - which is what we want: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming from DW_AT_name, gets created first, it wins, and the symtab ends up with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks. This is not wrong per-se, after all DW_AT_name is "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile a file passing "/an/absolute/path.c", DW_AT_name typically contains (at least with GCC) "/an/absolute/path.c" and GDB tells you that the source file is "/an/absolute/path.c". But we can also keep the existing behavior fairly easily with a little change in find_file_and_directory. When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now modify the name to just keep the file part. The result is coherent with what compilers do when you compile a file by just passing its filename ("gcc path.c -g"): DW_AT_name ("path.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") With this change, filename_for_id is still the full name, "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile / symtab (what ends up shown by "info source") is just "dw2-compdir-oldgcc42.S", and that makes the test happy. Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
2022-07-29gdb: add debug prints in buildsym.cSimon Marchi1-0/+7
Add a few debug prints in buildsym.c that were helpful to me in writing this series. Change-Id: If10a818feaee3ce1b78a2a254013b62dd578002b
2022-06-12Use malloc for mutable addrmapsTom Tromey1-9/+3
Mutable addrmaps currently require an obstack. This was probably done to avoid having to call splay_tree_delete, but examination of the code shows that all mutable obstacks have a limited lifetime -- now it's simple to treat them as ordinary C++ objects, in some cases stack-allocating them, and have a destructor to make the needed call. This patch implements this change.
2022-06-12Remove addrmap::create_fixedTom Tromey1-1/+2
addrmap::create_fixed is just a simple wrapper for 'new', so remove it in favor of uses of 'new'.
2022-06-12Remove addrmap_create_mutableTom Tromey1-1/+3
This removes addrmap_create_mutable in favor of using 'new' at the spots where the addrmap is created.
2022-06-12Remove addrmap wrapper functionsTom Tromey1-2/+2
This removes the various addrmap wrapper functions in favor of simple method calls on the objects themselves.
2022-04-27gdb: remove BLOCKVECTOR_MAP macroSimon Marchi1-3/+3
Replace with equivalent methods. Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi1-15/+13
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_MULTIDICT macroSimon Marchi1-12/+12
Replace with equivalent methods. Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
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-8/+6
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi1-23/+25
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-21gdbsupport: add path_join functionSimon Marchi1-2/+3
In this review [1], Eli pointed out that we should be careful when concatenating file names to avoid duplicated slashes. On Windows, a double slash at the beginning of a file path has a special meaning. So naively concatenating "/" and "foo/bar" would give "//foo/bar", which would not give the desired results. We already have a few spots doing: if (first_path ends with a slash) path = first_path + second_path else path = first_path + slash + second_path In general, I think it's nice to avoid superfluous slashes in file paths, since they might end up visible to the user and look a bit unprofessional. Introduce the path_join function that can be used to join multiple path components together (along with unit tests). I initially wanted to make it possible to join two absolute paths, to support the use case of prepending a sysroot path to a target file path, or the prepending the debug-file-directory to a target file path. But the code in solib_find_1 shows that it is more complex than this anyway (for example, when the right hand side is a Windows path with a drive letter). So I don't think we need to support that case in path_join. That also keeps the implementation simpler. Change a few spots to use path_join to show how it can be used. I believe that all the spots I changed are guarded by some checks that ensure the right hand side operand is not an absolute path. Regression-tested on Ubuntu 18.04. Built-tested on Windows, and I also ran the new unit-test there. [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752
2022-04-20Replace symbol_symtab with symbol::symtabTom Tromey1-6/+6
This turns symbol_symtab into a method on symbol. It also replaces symbol_set_symtab with a method.
2022-04-12gdb: change subfile::line_vector to an std::vectorSimon Marchi1-60/+34
Change this field to an std::vector to facilitate memory management. Since the linetable_entry array is copied into the symtab resulting from the subfile, it is possible to change it without changing how symtab stores the linetable entries (which would be a much larger change). There is a small change in buildsym_compunit::record_line to avoid accessing a now invalid linetable_entry. Before this patch, we keep a pointer to the last linetable entry, pop it from the vector, and then read last->line. It works with the manually-maintained array, but since we now use std::vector::pop_back, I am afraid that it could be flagged as an invalid access by the various static / dynamic analysis tools to access the linetable_entry object after popping it from the vector. Instead, record just the line number in an optional and use it. There are substantial changes in xcoffread.c that simplify the code, but I can't test them. I was hesitant to do this change because of that, but I decided to send it anyway. I don't think that an almost dead platform should hold back improving the code in the common parts of GDB. The changes in xcoffread.c are: - Make arrange_linetable "arrange" the linetable passed as a parameter, instead of returning possibly a new one, possibly the same one. - In the "Process main file's line numbers.", I'm not too sure what happens. We get the lintable from "main_subfile", "arrange" it, but then assign the result to the current subfile, obtained with get_current_subfile. I assume that the current subfile is also the main one, so now I just call arrange_linetable on the main subfile's line table. - Remove that weird "Useless if!!!" FIXME comment. It's been there forever, but the "if" is still there, so I guess the "if" can stay there. Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80
2022-04-12gdb: change subfile::name and buildsym_compunit::m_comp_dir to stringsSimon Marchi1-35/+29
Change subfile::name to be a string, for easier memory management. Change buildsym_compunit::m_comp_dir as well, since we move one in to the other at some point in patch_subfile_names, so it's easier to do both at the same time. There are various NULL checks for both fields currently, replace them with empty checks, I think it ends up equivalent. I can't test the change in xcoffread.c, it's best-effort. Change-Id: I62b5fb08b2089e096768a090627ac7617e90a016
2022-04-12gdb: allocate subfile with newSimon Marchi1-21/+16
Allocate struct subfile with new, initialize its fields instead of memset-ing it to 0. Use a unique_ptr for the window after a subfile has been allocated but before it is linked in the buildsym_compunit's list of subfile (and therefore owned by the buildsym_compunit. I can't test the change in xcoffread.c, it's best-effort. I couldn't find where subfiles are freed in that file, I assume they were intentionally (or not) leaked. Change-Id: Ib3b6877de31b7e65bc466682f08dbf5840225f24
2022-04-11gdb: remove symbol value macrosSimon Marchi1-1/+1
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 subfile::buildsym_compunit fieldSimon Marchi1-1/+0
It is only set, never used. Change-Id: Ia46ed2f9da243b0ccfc4588c1b57be2a0f3939de
2022-04-04gdb: Add support for DW_LNS_set_prologue_end in line-tableLancelot SIX1-0/+1
Add support for DW_LNS_set_prologue_end when building line-tables. This attribute can be set by the compiler to indicate that an instruction is an adequate place to set a breakpoint just after the prologue of a function. The compiler might set multiple prologue_end, but considering how current skip_prologue_using_sal works, this commit modifies it to accept the first instruction with this marker (if any) to be the place where a breakpoint should be placed to be at the end of the prologue. The need for this support came from a problematic usecase generated by hipcc (i.e. clang). The problem is as follows: There's a function (lets call it foo) which covers PC from 0xa800 to 0xa950. The body of foo begins with a call to an inlined function, covering from 0xa800 to 0xa94c. The issue is that when placing a breakpoint at 'foo', GDB inserts the breakpoint at 0xa818. The 0x18 offset is what GDB thinks is foo's first address past the prologue. Later, when hitting the breakpoint, GDB reports the stop within the inlined function because the PC falls in its range while the user expects to stop in FOO. Looking at the line-table for this location, we have: INDEX LINE ADDRESS IS-STMT [...] 14 293 0x000000000000a66c Y 15 END 0x000000000000a6e0 Y 16 287 0x000000000000a800 Y 17 END 0x000000000000a818 Y 18 287 0x000000000000a824 Y [...] For comparison, let's look at llvm-dwarfdump's output for this CU: Address Line Column File ISA Discriminator Flags ------------------ ------ ------ ------ --- ------------- ------------- [...] 0x000000000000a66c 293 12 2 0 0 is_stmt 0x000000000000a6e0 96 43 82 0 0 is_stmt 0x000000000000a6f8 102 18 82 0 0 is_stmt 0x000000000000a70c 102 24 82 0 0 0x000000000000a710 102 18 82 0 0 0x000000000000a72c 101 16 82 0 0 is_stmt 0x000000000000a73c 2915 50 83 0 0 is_stmt 0x000000000000a74c 110 1 1 0 0 is_stmt 0x000000000000a750 110 1 1 0 0 is_stmt end_sequence 0x000000000000a800 107 0 1 0 0 is_stmt 0x000000000000a800 287 12 2 0 0 is_stmt prologue_end 0x000000000000a818 114 59 81 0 0 is_stmt 0x000000000000a824 287 12 2 0 0 is_stmt 0x000000000000a828 100 58 82 0 0 is_stmt [...] The main difference we are interested in here is that llvm-dwarfdump's output tells us that 0xa800 is an adequate place to place a breakpoint past a function prologue. Since we know that foo covers from 0xa800 to 0xa94c, 0xa800 is the address at which the breakpoint should be placed if the user wants to break in foo. This commit proposes to add support for the prologue_end flag in the line-program processing. The processing of this prologue_end flag is made in skip_prologue_sal, before it calls gdbarch_skip_prologue_noexcept. The intent is that if the compiler gave information on where the prologue ends, we should use this information and not try to rely on architecture dependent logic to guess it. The testsuite have been executed using this patch on GNU/Linux x86_64. Testcases have been compiled with both gcc/g++ (verison 9.4.0) and clang/clang++ (version 10.0.0) since at the time of writing GCC does not set the prologue_end marker. Tests done with GCC 11.2.0 (not over the entire testsuite) show that it does not emit this flag either. No regression have been observed with GCC or Clang. Note that when using Clang, this patch fixes a failure in gdb.opt/inline-small-func.exp. Change-Id: I720449a8a9b2e1fb45b54c6095d3b1e9da9152f8
2022-04-04gdb/buildsym: Line record use a record flagLancelot SIX1-2/+2
Currently when recording a line entry (with buildsym_compunit::record_line), a boolean argument argument is used to indicate that the is_stmt flag should be set for this particular record. As a later commit will add support for new flags, instead of adding a parameter to record_line for each possible flag, transform the current is_stmt parameter into a enum flag. This flags parameter will allow greater flexibility in future commits. This enum flags type is not propagated into the linetable_entry type as this would require a lot of changes across the codebase for no practical gain (it currently uses a bitfield where each interesting flag only occupy 1 bit in the structure). Tested on x86_64-linux, no regression observed. Change-Id: I5d061fa67bdb34918742505ff983d37453839d6a
2022-04-04gdb: rename start_symtab/end_symtab to start_compunit_symtab/end_compunit_symtabSimon Marchi1-30/+34
It's a bit confusing because we have both "compunit_symtab" and "symtab" types, and many methods and functions containing "start_symtab" or "end_symtab", which actually deal with compunit_symtabs. I believe this comes from the time before compunit_symtab was introduced, where symtab did the job of both. Rename everything I found containing start_symtab or end_symtab to use start_compunit_symtab or end_compunit_symtab. Change-Id: If3849b156f6433640173085ad479b6a0b085ade2
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_IS_ARGUMENT macroSimon Marchi1-2/+2
Add a getter and a setter for whether a symbol is an argument. Remove the corresponding macro and adjust all callers. Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
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 SYMTAB_LINETABLE macro, add getter/setterSimon Marchi1-7/+5
Add a getter and a setter for a symtab's linetable. Remove the corresponding macro and adjust all callers. Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c
2022-02-06gdb: remove COMPUNIT_MACRO_TABLE macro, add getter/setterSimon Marchi1-1/+1
Add a getter and a setter for a compunit_symtab's macro table. Remove the corresponding macro and adjust all callers. Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a
2022-02-06gdb: remove COMPUNIT_BLOCK_LINE_SECTION macro, add getter/setterSimon Marchi1-1/+1
Add a getter and a setter for a compunit_symtab's block line section. Remove the corresponding macro and adjust all callers. Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455
2022-02-06gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setterSimon Marchi1-2/+2
Add a getter and a setter for a compunit_symtab's blockvector. Remove the corresponding macro and adjust all callers. Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64
2022-02-06gdb: remove COMPUNIT_DIRNAME macro, add getter/setterSimon Marchi1-2/+2
Add a getter and a setter for a compunit_symtab's dirname. Remove the corresponding macro and adjust all callers. Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e
2022-02-06gdb: remove COMPUNIT_PRODUCER macro, add getter/setterSimon Marchi1-1/+1
Add a getter and a setter for a compunit_symtab's producer. Remove the corresponding macro and adjust all callers. Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
2022-02-06gdb: remove COMPUNIT_DEBUGFORMAT macro, add getter/setterSimon Marchi1-1/+1
Add a getter and a setter for a compunit_symtab's debugformat. Remove the corresponding macro and adjust all callers. Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975
2022-02-06gdb: remove COMPUNIT_FILETABS macroSimon Marchi1-2/+2
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-06gdb: add compunit_symtab::set_primary_filetab methodSimon Marchi1-22/+2
Add a method to set the primary filetab of the CU. This is currently done in buildsym_compunit::end_symtab_with_blockvector. Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74
2022-01-18Move gdb obstack code to gdbsupportTom Tromey1-1/+1
This moves the gdb-specific obstack code -- both extensions like obconcat and obstack_strdup, and things like auto_obstack -- to gdbsupport.
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-01-04[gdb/symtab] Remove superfluous end-of-sequence markerTom de Vries1-2/+7
While working on PR26935 I noticed that when running test-case gdb.base/morestack.exp with target board unix/-m32/-fPIE/-pie and ld linker, I get this linetable fragment for morestack.S using readelf -wL: ... CU: ../../../../libgcc/config/i386/morestack.S: Line number Starting address View Stmt 109 0xc9c x ... 838 0xe03 x - 0xe04 636 0 x 637 0x3 x - 0x4 ... but with "maint info line-table" I get: ... INDEX LINE ADDRESS IS-STMT 0 END 0x00000004 Y 1 109 0x00000c9c Y ... 110 838 0x00000e03 Y 111 END 0x00000e04 Y ... So, apparently the entries with addresses 0x0 and 0x3 are filtered out because the addresses are out of range, but the same doesn't happen with the end-of-seq terminator. Fix this by filtering out end-of-seq terminators that do not actually terminate anything. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * buildsym.c (buildsym_compunit::record_line): Filter out end-of-seq terminators that do not terminate anything. gdb/testsuite/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: New file.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-11-02gdb, gdbserver, gdbsupport: fix leading space vs tabs issuesSimon Marchi1-9/+9
Many spots incorrectly use only spaces for indentation (for example, there are a lot of spots in ada-lang.c). I've always found it awkward when I needed to edit one of these spots: do I keep the original wrong indentation, or do I fix it? What if the lines around it are also wrong, do I fix them too? I probably don't want to fix them in the same patch, to avoid adding noise to my patch. So I propose to fix as much as possible once and for all (hopefully). One typical counter argument for this is that it makes code archeology more difficult, because git-blame will show this commit as the last change for these lines. My counter counter argument is: when git-blaming, you often need to do "blame the file at the parent commit" anyway, to go past some other refactor that touched the line you are interested in, but is not the change you are looking for. So you already need a somewhat efficient way to do this. Using some interactive tool, rather than plain git-blame, makes this trivial. For example, I use "tig blame <file>", where going back past the commit that changed the currently selected line is one keystroke. It looks like Magit in Emacs does it too (though I've never used it). Web viewers of Github and Gitlab do it too. My point is that it won't really make archeology more difficult. The other typical counter argument is that it will cause conflicts with existing patches. That's true... but it's a one time cost, and those are not conflicts that are difficult to resolve. I have also tried "git rebase --ignore-whitespace", it seems to work well. Although that will re-introduce the faulty indentation, so one needs to take care of fixing the indentation in the patch after that (which is easy). gdb/ChangeLog: * aarch64-linux-tdep.c: Fix indentation. * aarch64-ravenscar-thread.c: Fix indentation. * aarch64-tdep.c: Fix indentation. * aarch64-tdep.h: Fix indentation. * ada-lang.c: Fix indentation. * ada-lang.h: Fix indentation. * ada-tasks.c: Fix indentation. * ada-typeprint.c: Fix indentation. * ada-valprint.c: Fix indentation. * ada-varobj.c: Fix indentation. * addrmap.c: Fix indentation. * addrmap.h: Fix indentation. * agent.c: Fix indentation. * aix-thread.c: Fix indentation. * alpha-bsd-nat.c: Fix indentation. * alpha-linux-tdep.c: Fix indentation. * alpha-mdebug-tdep.c: Fix indentation. * alpha-nbsd-tdep.c: Fix indentation. * alpha-obsd-tdep.c: Fix indentation. * alpha-tdep.c: Fix indentation. * amd64-bsd-nat.c: Fix indentation. * amd64-darwin-tdep.c: Fix indentation. * amd64-linux-nat.c: Fix indentation. * amd64-linux-tdep.c: Fix indentation. * amd64-nat.c: Fix indentation. * amd64-obsd-tdep.c: Fix indentation. * amd64-tdep.c: Fix indentation. * amd64-windows-tdep.c: Fix indentation. * annotate.c: Fix indentation. * arc-tdep.c: Fix indentation. * arch-utils.c: Fix indentation. * arch/arm-get-next-pcs.c: Fix indentation. * arch/arm.c: Fix indentation. * arm-linux-nat.c: Fix indentation. * arm-linux-tdep.c: Fix indentation. * arm-nbsd-tdep.c: Fix indentation. * arm-pikeos-tdep.c: Fix indentation. * arm-tdep.c: Fix indentation. * arm-tdep.h: Fix indentation. * arm-wince-tdep.c: Fix indentation. * auto-load.c: Fix indentation. * auxv.c: Fix indentation. * avr-tdep.c: Fix indentation. * ax-gdb.c: Fix indentation. * ax-general.c: Fix indentation. * bfin-linux-tdep.c: Fix indentation. * block.c: Fix indentation. * block.h: Fix indentation. * blockframe.c: Fix indentation. * bpf-tdep.c: Fix indentation. * break-catch-sig.c: Fix indentation. * break-catch-syscall.c: Fix indentation. * break-catch-throw.c: Fix indentation. * breakpoint.c: Fix indentation. * breakpoint.h: Fix indentation. * bsd-uthread.c: Fix indentation. * btrace.c: Fix indentation. * build-id.c: Fix indentation. * buildsym-legacy.h: Fix indentation. * buildsym.c: Fix indentation. * c-typeprint.c: Fix indentation. * c-valprint.c: Fix indentation. * c-varobj.c: Fix indentation. * charset.c: Fix indentation. * cli/cli-cmds.c: Fix indentation. * cli/cli-decode.c: Fix indentation. * cli/cli-decode.h: Fix indentation. * cli/cli-script.c: Fix indentation. * cli/cli-setshow.c: Fix indentation. * coff-pe-read.c: Fix indentation. * coffread.c: Fix indentation. * compile/compile-cplus-types.c: Fix indentation. * compile/compile-object-load.c: Fix indentation. * compile/compile-object-run.c: Fix indentation. * completer.c: Fix indentation. * corefile.c: Fix indentation. * corelow.c: Fix indentation. * cp-abi.h: Fix indentation. * cp-namespace.c: Fix indentation. * cp-support.c: Fix indentation. * cp-valprint.c: Fix indentation. * cris-linux-tdep.c: Fix indentation. * cris-tdep.c: Fix indentation. * darwin-nat-info.c: Fix indentation. * darwin-nat.c: Fix indentation. * darwin-nat.h: Fix indentation. * dbxread.c: Fix indentation. * dcache.c: Fix indentation. * disasm.c: Fix indentation. * dtrace-probe.c: Fix indentation. * dwarf2/abbrev.c: Fix indentation. * dwarf2/attribute.c: Fix indentation. * dwarf2/expr.c: Fix indentation. * dwarf2/frame.c: Fix indentation. * dwarf2/index-cache.c: Fix indentation. * dwarf2/index-write.c: Fix indentation. * dwarf2/line-header.c: Fix indentation. * dwarf2/loc.c: Fix indentation. * dwarf2/macro.c: Fix indentation. * dwarf2/read.c: Fix indentation. * dwarf2/read.h: Fix indentation. * elfread.c: Fix indentation. * eval.c: Fix indentation. * event-top.c: Fix indentation. * exec.c: Fix indentation. * exec.h: Fix indentation. * expprint.c: Fix indentation. * f-lang.c: Fix indentation. * f-typeprint.c: Fix indentation. * f-valprint.c: Fix indentation. * fbsd-nat.c: Fix indentation. * fbsd-tdep.c: Fix indentation. * findvar.c: Fix indentation. * fork-child.c: Fix indentation. * frame-unwind.c: Fix indentation. * frame-unwind.h: Fix indentation. * frame.c: Fix indentation. * frv-linux-tdep.c: Fix indentation. * frv-tdep.c: Fix indentation. * frv-tdep.h: Fix indentation. * ft32-tdep.c: Fix indentation. * gcore.c: Fix indentation. * gdb_bfd.c: Fix indentation. * gdbarch.sh: Fix indentation. * gdbarch.c: Re-generate * gdbarch.h: Re-generate. * gdbcore.h: Fix indentation. * gdbthread.h: Fix indentation. * gdbtypes.c: Fix indentation. * gdbtypes.h: Fix indentation. * glibc-tdep.c: Fix indentation. * gnu-nat.c: Fix indentation. * gnu-nat.h: Fix indentation. * gnu-v2-abi.c: Fix indentation. * gnu-v3-abi.c: Fix indentation. * go32-nat.c: Fix indentation. * guile/guile-internal.h: Fix indentation. * guile/scm-cmd.c: Fix indentation. * guile/scm-frame.c: Fix indentation. * guile/scm-iterator.c: Fix indentation. * guile/scm-math.c: Fix indentation. * guile/scm-ports.c: Fix indentation. * guile/scm-pretty-print.c: Fix indentation. * guile/scm-value.c: Fix indentation. * h8300-tdep.c: Fix indentation. * hppa-linux-nat.c: Fix indentation. * hppa-linux-tdep.c: Fix indentation. * hppa-nbsd-nat.c: Fix indentation. * hppa-nbsd-tdep.c: Fix indentation. * hppa-obsd-nat.c: Fix indentation. * hppa-tdep.c: Fix indentation. * hppa-tdep.h: Fix indentation. * i386-bsd-nat.c: Fix indentation. * i386-darwin-nat.c: Fix indentation. * i386-darwin-tdep.c: Fix indentation. * i386-dicos-tdep.c: Fix indentation. * i386-gnu-nat.c: Fix indentation. * i386-linux-nat.c: Fix indentation. * i386-linux-tdep.c: Fix indentation. * i386-nto-tdep.c: Fix indentation. * i386-obsd-tdep.c: Fix indentation. * i386-sol2-nat.c: Fix indentation. * i386-tdep.c: Fix indentation. * i386-tdep.h: Fix indentation. * i386-windows-tdep.c: Fix indentation. * i387-tdep.c: Fix indentation. * i387-tdep.h: Fix indentation. * ia64-libunwind-tdep.c: Fix indentation. * ia64-libunwind-tdep.h: Fix indentation. * ia64-linux-nat.c: Fix indentation. * ia64-linux-tdep.c: Fix indentation. * ia64-tdep.c: Fix indentation. * ia64-tdep.h: Fix indentation. * ia64-vms-tdep.c: Fix indentation. * infcall.c: Fix indentation. * infcmd.c: Fix indentation. * inferior.c: Fix indentation. * infrun.c: Fix indentation. * iq2000-tdep.c: Fix indentation. * language.c: Fix indentation. * linespec.c: Fix indentation. * linux-fork.c: Fix indentation. * linux-nat.c: Fix indentation. * linux-tdep.c: Fix indentation. * linux-thread-db.c: Fix indentation. * lm32-tdep.c: Fix indentation. * m2-lang.c: Fix indentation. * m2-typeprint.c: Fix indentation. * m2-valprint.c: Fix indentation. * m32c-tdep.c: Fix indentation. * m32r-linux-tdep.c: Fix indentation. * m32r-tdep.c: Fix indentation. * m68hc11-tdep.c: Fix indentation. * m68k-bsd-nat.c: Fix indentation. * m68k-linux-nat.c: Fix indentation. * m68k-linux-tdep.c: Fix indentation. * m68k-tdep.c: Fix indentation. * machoread.c: Fix indentation. * macrocmd.c: Fix indentation. * macroexp.c: Fix indentation. * macroscope.c: Fix indentation. * macrotab.c: Fix indentation. * macrotab.h: Fix indentation. * main.c: Fix indentation. * mdebugread.c: Fix indentation. * mep-tdep.c: Fix indentation. * mi/mi-cmd-catch.c: Fix indentation. * mi/mi-cmd-disas.c: Fix indentation. * mi/mi-cmd-env.c: Fix indentation. * mi/mi-cmd-stack.c: Fix indentation. * mi/mi-cmd-var.c: Fix indentation. * mi/mi-cmds.c: Fix indentation. * mi/mi-main.c: Fix indentation. * mi/mi-parse.c: Fix indentation. * microblaze-tdep.c: Fix indentation. * minidebug.c: Fix indentation. * minsyms.c: Fix indentation. * mips-linux-nat.c: Fix indentation. * mips-linux-tdep.c: Fix indentation. * mips-nbsd-tdep.c: Fix indentation. * mips-tdep.c: Fix indentation. * mn10300-linux-tdep.c: Fix indentation. * mn10300-tdep.c: Fix indentation. * moxie-tdep.c: Fix indentation. * msp430-tdep.c: Fix indentation. * namespace.h: Fix indentation. * nat/fork-inferior.c: Fix indentation. * nat/gdb_ptrace.h: Fix indentation. * nat/linux-namespaces.c: Fix indentation. * nat/linux-osdata.c: Fix indentation. * nat/netbsd-nat.c: Fix indentation. * nat/x86-dregs.c: Fix indentation. * nbsd-nat.c: Fix indentation. * nbsd-tdep.c: Fix indentation. * nios2-linux-tdep.c: Fix indentation. * nios2-tdep.c: Fix indentation. * nto-procfs.c: Fix indentation. * nto-tdep.c: Fix indentation. * objfiles.c: Fix indentation. * objfiles.h: Fix indentation. * opencl-lang.c: Fix indentation. * or1k-tdep.c: Fix indentation. * osabi.c: Fix indentation. * osabi.h: Fix indentation. * osdata.c: Fix indentation. * p-lang.c: Fix indentation. * p-typeprint.c: Fix indentation. * p-valprint.c: Fix indentation. * parse.c: Fix indentation. * ppc-linux-nat.c: Fix indentation. * ppc-linux-tdep.c: Fix indentation. * ppc-nbsd-nat.c: Fix indentation. * ppc-nbsd-tdep.c: Fix indentation. * ppc-obsd-nat.c: Fix indentation. * ppc-ravenscar-thread.c: Fix indentation. * ppc-sysv-tdep.c: Fix indentation. * ppc64-tdep.c: Fix indentation. * printcmd.c: Fix indentation. * proc-api.c: Fix indentation. * producer.c: Fix indentation. * producer.h: Fix indentation. * prologue-value.c: Fix indentation. * prologue-value.h: Fix indentation. * psymtab.c: Fix indentation. * python/py-arch.c: Fix indentation. * python/py-bpevent.c: Fix indentation. * python/py-event.c: Fix indentation. * python/py-event.h: Fix indentation. * python/py-finishbreakpoint.c: Fix indentation. * python/py-frame.c: Fix indentation. * python/py-framefilter.c: Fix indentation. * python/py-inferior.c: Fix indentation. * python/py-infthread.c: Fix indentation. * python/py-objfile.c: Fix indentation. * python/py-prettyprint.c: Fix indentation. * python/py-registers.c: Fix indentation. * python/py-signalevent.c: Fix indentation. * python/py-stopevent.c: Fix indentation. * python/py-stopevent.h: Fix indentation. * python/py-threadevent.c: Fix indentation. * python/py-tui.c: Fix indentation. * python/py-unwind.c: Fix indentation. * python/py-value.c: Fix indentation. * python/py-xmethods.c: Fix indentation. * python/python-internal.h: Fix indentation. * python/python.c: Fix indentation. * ravenscar-thread.c: Fix indentation. * record-btrace.c: Fix indentation. * record-full.c: Fix indentation. * record.c: Fix indentation. * reggroups.c: Fix indentation. * regset.h: Fix indentation. * remote-fileio.c: Fix indentation. * remote.c: Fix indentation. * reverse.c: Fix indentation. * riscv-linux-tdep.c: Fix indentation. * riscv-ravenscar-thread.c: Fix indentation. * riscv-tdep.c: Fix indentation. * rl78-tdep.c: Fix indentation. * rs6000-aix-tdep.c: Fix indentation. * rs6000-lynx178-tdep.c: Fix indentation. * rs6000-nat.c: Fix indentation. * rs6000-tdep.c: Fix indentation. * rust-lang.c: Fix indentation. * rx-tdep.c: Fix indentation. * s12z-tdep.c: Fix indentation. * s390-linux-tdep.c: Fix indentation. * score-tdep.c: Fix indentation. * ser-base.c: Fix indentation. * ser-mingw.c: Fix indentation. * ser-uds.c: Fix indentation. * ser-unix.c: Fix indentation. * serial.c: Fix indentation. * sh-linux-tdep.c: Fix indentation. * sh-nbsd-tdep.c: Fix indentation. * sh-tdep.c: Fix indentation. * skip.c: Fix indentation. * sol-thread.c: Fix indentation. * solib-aix.c: Fix indentation. * solib-darwin.c: Fix indentation. * solib-frv.c: Fix indentation. * solib-svr4.c: Fix indentation. * solib.c: Fix indentation. * source.c: Fix indentation. * sparc-linux-tdep.c: Fix indentation. * sparc-nbsd-tdep.c: Fix indentation. * sparc-obsd-tdep.c: Fix indentation. * sparc-ravenscar-thread.c: Fix indentation. * sparc-tdep.c: Fix indentation. * sparc64-linux-tdep.c: Fix indentation. * sparc64-nbsd-tdep.c: Fix indentation. * sparc64-obsd-tdep.c: Fix indentation. * sparc64-tdep.c: Fix indentation. * stabsread.c: Fix indentation. * stack.c: Fix indentation. * stap-probe.c: Fix indentation. * stubs/ia64vms-stub.c: Fix indentation. * stubs/m32r-stub.c: Fix indentation. * stubs/m68k-stub.c: Fix indentation. * stubs/sh-stub.c: Fix indentation. * stubs/sparc-stub.c: Fix indentation. * symfile-mem.c: Fix indentation. * symfile.c: Fix indentation. * symfile.h: Fix indentation. * symmisc.c: Fix indentation. * symtab.c: Fix indentation. * symtab.h: Fix indentation. * target-float.c: Fix indentation. * target.c: Fix indentation. * target.h: Fix indentation. * tic6x-tdep.c: Fix indentation. * tilegx-linux-tdep.c: Fix indentation. * tilegx-tdep.c: Fix indentation. * top.c: Fix indentation. * tracefile-tfile.c: Fix indentation. * tracepoint.c: Fix indentation. * tui/tui-disasm.c: Fix indentation. * tui/tui-io.c: Fix indentation. * tui/tui-regs.c: Fix indentation. * tui/tui-stack.c: Fix indentation. * tui/tui-win.c: Fix indentation. * tui/tui-winsource.c: Fix indentation. * tui/tui.c: Fix indentation. * typeprint.c: Fix indentation. * ui-out.h: Fix indentation. * unittests/copy_bitwise-selftests.c: Fix indentation. * unittests/memory-map-selftests.c: Fix indentation. * utils.c: Fix indentation. * v850-tdep.c: Fix indentation. * valarith.c: Fix indentation. * valops.c: Fix indentation. * valprint.c: Fix indentation. * valprint.h: Fix indentation. * value.c: Fix indentation. * value.h: Fix indentation. * varobj.c: Fix indentation. * vax-tdep.c: Fix indentation. * windows-nat.c: Fix indentation. * windows-tdep.c: Fix indentation. * xcoffread.c: Fix indentation. * xml-syscall.c: Fix indentation. * xml-tdesc.c: Fix indentation. * xstormy16-tdep.c: Fix indentation. * xtensa-config.c: Fix indentation. * xtensa-linux-nat.c: Fix indentation. * xtensa-linux-tdep.c: Fix indentation. * xtensa-tdep.c: Fix indentation. gdbserver/ChangeLog: * ax.cc: Fix indentation. * dll.cc: Fix indentation. * inferiors.h: Fix indentation. * linux-low.cc: Fix indentation. * linux-nios2-low.cc: Fix indentation. * linux-ppc-ipa.cc: Fix indentation. * linux-ppc-low.cc: Fix indentation. * linux-x86-low.cc: Fix indentation. * linux-xtensa-low.cc: Fix indentation. * regcache.cc: Fix indentation. * server.cc: Fix indentation. * tracepoint.cc: Fix indentation. gdbsupport/ChangeLog: * common-exceptions.h: Fix indentation. * event-loop.cc: Fix indentation. * fileio.cc: Fix indentation. * filestuff.cc: Fix indentation. * gdb-dlfcn.cc: Fix indentation. * gdb_string_view.h: Fix indentation. * job-control.cc: Fix indentation. * signals.cc: Fix indentation. Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-07-06[gdb/symtab] Fix line-table end-of-sequence sortingTom de Vries1-0/+4
Consider test-case gdb.dwarf2/dw2-ranges-base.exp. It has (ignoring non-sensical entries that are filtered out by buildsym_compunit::record_line) a line-table for dw2-ranges-base.c like this: ... Line Number Statements: [0x0000014e] Extended opcode 2: set Address to 0x4004ba [0x00000159] Advance Line by 10 to 11 [0x0000015b] Copy [0x0000015c] Advance PC by 12 to 0x4004c6 [0x0000015e] Extended opcode 1: End of Sequence [0x00000161] Extended opcode 2: set Address to 0x4004ae [0x0000016c] Advance Line by 20 to 21 [0x0000016e] Copy [0x0000016f] Advance PC by 12 to 0x4004ba [0x00000171] Extended opcode 1: End of Sequence [0x00000174] Extended opcode 2: set Address to 0x4004a7 [0x0000017f] Advance Line by 30 to 31 [0x00000181] Copy [0x00000182] Advance PC by 7 to 0x4004ae [0x00000184] Extended opcode 1: End of Sequence ... If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector, we have the unsorted line table: ... INDEX LINE ADDRESS IS-STMT 0 11 0x00000000004004ba Y 1 END 0x00000000004004c6 Y 2 21 0x00000000004004ae Y 3 END 0x00000000004004ba Y 4 31 0x00000000004004a7 Y 5 END 0x00000000004004ae Y ... It contains 3 sequences, 11/END, 21/END and 31/END. We want to sort the 3 sequences relative to each other, while sorting on address, to get: ... INDEX LINE ADDRESS IS-STMT 0 31 0x00000000004004a7 Y 1 END 0x00000000004004ae Y 2 21 0x00000000004004ae Y 3 END 0x00000000004004ba Y 4 11 0x00000000004004ba Y 5 END 0x00000000004004c6 Y ... However, if we re-enable the sorting, we have instead: ... INDEX LINE ADDRESS IS-STMT 0 31 0x00000000004004a7 Y 1 21 0x00000000004004ae Y 2 END 0x00000000004004ae Y 3 11 0x00000000004004ba Y 4 END 0x00000000004004ba Y 5 END 0x00000000004004c6 Y ... This is a regression since commit 3d92a3e313 "gdb: Don't reorder line table entries too much when sorting", that introduced sorting on address while keeping entries with the same address in pre-sort order. Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5 in the unsorted line table), but entry 1 does not belong in the sequence terminated by 2. Fix this by handling End-Of-Sequence entries in the sorting function, such that they are sorted before other entries with the same address. Also, revert the find_pc_sect_line workaround introduced in commit 3d92a3e313, since that's no longer necessary. Tested on x86_64-linux. gdb/ChangeLog: 2020-07-06 Tom de Vries <tdevries@suse.de> * buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle End-Of-Sequence in lte_is_less_than. * symtab.c (find_pc_sect_line): Revert change from commit 3d92a3e313 "gdb: Don't reorder line table entries too much when sorting". gdb/testsuite/ChangeLog: 2020-07-06 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.
2020-06-08gdb: add field::type / field::set_typeSimon Marchi1-1/+1
Add the `type` and `set_type` methods on `struct field`, in order to remoremove the `FIELD_TYPE` macro. In this patch, the `FIELD_TYPE` macro is changed to use `field::type`, so all the call sites that are useused to set the field's type are changed to use `field::set_type`. The next patch will remove `FIELD_TYPE` completely. Note that because of the name clash between the existing field named `type` and the new method, I renamed the field `m_type`. It is not private per-se, because we can't make `struct field` a non-POD yet, but it should be considered private anyway (not accessed outside `struct field`). gdb/ChangeLog: * gdbtypes.h (struct field) <type, set_type>: New methods. Rename `type` field to... <m_type>: ... this. Change references throughout to use type or set_type methods. (FIELD_TYPE): Use field::type. Change call sites that modify the field's type to use field::set_type instead. Change-Id: Ie21f866e3b7f8a51ea49b722d07d272a724459a0
2020-05-22gdb: add type::fields / type::set_fieldsSimon Marchi1-2/+3
Add the `fields` and `set_fields` methods on `struct type`, in order to remove the `TYPE_FIELDS` macro. In this patch, the `TYPE_FIELDS` macro is changed to the `type::fields`, so all the call sites that use it to set the fields array are changed to use `type::set_fields`. The next patch will remove `TYPE_FIELDS` entirely. gdb/ChangeLog: * gdbtypes.h (struct type) <fields, set_fields>: New methods. (TYPE_FIELDS): Use type::fields. Change all call sites that modify the propery to use type::set_fields instead. Change-Id: I05174ce68f2ce3fccdf5d8b469ff141f14886b33
2020-05-22gdb: remove TYPE_NFIELDS macroSimon Marchi1-1/+1
Remove `TYPE_NFIELDS`, changing all the call sites to use `type::num_fields` directly. This is quite a big diff, but this was mostly done using sed and coccinelle. A few call sites were done by hand. gdb/ChangeLog: * gdbtypes.h (TYPE_NFIELDS): Remove. Change all cal sites to use type::num_fields instead. Change-Id: Ib73be4c36f9e770e0f729bac3b5257d7cb2f9591
2020-05-22gdb: add type::num_fields / type::set_num_fieldsSimon Marchi1-1/+1
Add the `num_fields` and `set_num_fields` methods on `struct type`, in order to remove the `TYPE_NFIELDS` macro. In this patch, the `TYPE_NFIELDS` macro is changed to use `type::num_fields`, so all the call sites that are used to set the number of fields are changed to use `type::set_num_fields`. The next patch will remove `TYPE_NFIELDS` completely. I think that in the future, we should consider making the interface of `struct type` better. For example, right now it's possible for the number of fields property and the actual number of fields set to be out of sync. However, I want to keep the existing behavior in this patch, just translate from macros to methods. gdb/ChangeLog: * gdbtypes.h (struct type) <num_fields, set_num_fields>: New methods. (TYPE_NFIELDS): Use type::num_fields. Change all call sites that modify the number of fields to use type::set_num_fields instead. Change-Id: I5ad9de5be4097feaf942d111077434bf91d13dc5
2020-04-18Change get_objfile_arch to a method on objfileTom Tromey1-1/+1
This changes get_objfile_arch to be a new inline method, objfile::arch. To my surprise, this function came up while profiling DWARF psymbol reading. Making this change improved performance from 1.986 seconds to 1.869 seconds. Both measurements were done by taking the mean of 10 runs on a fixed copy of the gdb executable. gdb/ChangeLog 2020-04-18 Tom Tromey <tom@tromey.com> * xcoffread.c (enter_line_range, scan_xcoff_symtab): Update. * value.c (value_fn_field): Update. * valops.c (find_function_in_inferior) (value_allocate_space_in_inferior): Update. * tui/tui-winsource.c (tui_update_source_windows_with_line): Update. * tui/tui-source.c (tui_source_window::set_contents): Update. * symtab.c (lookup_global_or_static_symbol) (find_function_start_sal_1, skip_prologue_sal) (print_msymbol_info, find_gnu_ifunc, symbol_arch): Update. * symmisc.c (dump_msymbols, dump_symtab_1) (maintenance_print_one_line_table): Update. * symfile.c (init_entry_point_info, section_is_mapped) (list_overlays_command, simple_read_overlay_table) (simple_overlay_update_1): Update. * stap-probe.c (handle_stap_probe): Update. * stabsread.c (dbx_init_float_type, define_symbol) (read_one_struct_field, read_enum_type, read_range_type): Update. * source.c (info_line_command): Update. * python/python.c (gdbpy_source_objfile_script) (gdbpy_execute_objfile_script): Update. * python/py-type.c (save_objfile_types): Update. * python/py-objfile.c (py_free_objfile): Update. * python/py-inferior.c (python_new_objfile): Update. * psymtab.c (psym_find_pc_sect_compunit_symtab, dump_psymtab) (dump_psymtab_addrmap_1, maintenance_info_psymtabs) (maintenance_check_psymtabs): Update. * printcmd.c (info_address_command): Update. * objfiles.h (struct objfile) <arch>: New method, from get_objfile_arch. (get_objfile_arch): Don't declare. * objfiles.c (get_objfile_arch): Remove. (filter_overlapping_sections): Update. * minsyms.c (msymbol_is_function): Update. * mi/mi-symbol-cmds.c (mi_cmd_symbol_list_lines) (output_nondebug_symbol): Update. * mdebugread.c (parse_symbol, basic_type, parse_partial_symbols) (mdebug_expand_psymtab): Update. * machoread.c (macho_add_oso_symfile): Update. * linux-tdep.c (linux_infcall_mmap, linux_infcall_munmap): Update. * linux-fork.c (checkpoint_command): Update. * linespec.c (convert_linespec_to_sals): Update. * jit.c (finalize_symtab): Update. * infrun.c (insert_exception_resume_from_probe): Update. * ia64-tdep.c (ia64_find_unwind_table): Update. * hppa-tdep.c (internalize_unwinds): Update. * gdbtypes.c (get_type_arch, init_float_type, objfile_type): Update. * gcore.c (call_target_sbrk): Update. * elfread.c (record_minimal_symbol, elf_symtab_read) (elf_rel_plt_read, elf_gnu_ifunc_record_cache) (elf_gnu_ifunc_resolve_by_got): Update. * dwarf2/read.c (create_addrmap_from_index) (create_addrmap_from_aranges, dw2_find_pc_sect_compunit_symtab) (read_debug_names_from_section) (process_psymtab_comp_unit_reader, add_partial_symbol) (add_partial_subprogram, process_full_comp_unit) (read_file_scope, read_func_scope, read_lexical_block_scope) (read_call_site_scope, dwarf2_ranges_read) (dwarf2_record_block_ranges, dwarf2_add_field) (mark_common_block_symbol_computed, read_tag_pointer_type) (read_tag_string_type, dwarf2_init_float_type) (dwarf2_init_complex_target_type, read_base_type) (partial_die_info::read, partial_die_info::read) (read_attribute_value, dwarf_decode_lines_1, new_symbol) (dwarf2_fetch_die_loc_sect_off): Update. * dwarf2/loc.c (dwarf2_find_location_expression) (class dwarf_evaluate_loc_desc, rw_pieced_value) (dwarf2_evaluate_loc_desc_full, dwarf2_locexpr_baton_eval) (dwarf2_loc_desc_get_symbol_read_needs) (locexpr_describe_location_piece, locexpr_describe_location_1) (loclist_describe_location): Update. * dwarf2/index-write.c (write_debug_names): Update. * dwarf2/frame.c (dwarf2_build_frame_info): Update. * dtrace-probe.c (dtrace_process_dof): Update. * dbxread.c (read_dbx_symtab, dbx_end_psymtab) (process_one_symbol): Update. * ctfread.c (ctf_init_float_type, read_base_type): Update. * coffread.c (coff_symtab_read, enter_linenos, decode_base_type) (coff_read_enum_type): Update. * cli/cli-cmds.c (edit_command, list_command): Update. * buildsym.c (buildsym_compunit::finish_block_internal): Update. * breakpoint.c (create_overlay_event_breakpoint) (create_longjmp_master_breakpoint) (create_std_terminate_master_breakpoint) (create_exception_master_breakpoint, get_sal_arch): Update. * block.c (block_gdbarch): Update. * annotate.c (annotate_source_line): Update.
2020-04-09Partially revert my UB fix in record_lineBernd Edlinger1-19/+18
This reverts the following commit partially: commit 64dc2d4bd24ff7119c913fff91184414f09b8042 Author: Bernd Edlinger <bernd.edlinger@hotmail.de> Date: Thu Mar 12 11:52:34 2020 +0100 Fix an undefined behavior in record_line Additionally do not completely remove symbols at the same PC than the end marker, instead make them non-is-stmt breakpoints. We keep the undefined behavoir fix, but have to restore the original behavior regarding deletion of the line entries. 2020-04-09 Bernd Edlinger <bernd.edlinger@hotmail.de> revert partially: 2020-04-01 Bernd Edlinger <bernd.edlinger@hotmail.de> * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof.
2020-04-02gdb: Don't remove duplicate entries from the line tableAndrew Burgess1-14/+0
In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-04-01Fix an undefined behavior in record_lineBernd Edlinger1-16/+18
Additionally do not completely remove symbols at the same PC than the end marker, instead make them non-is-stmt breakpoints. 2020-04-01 Bernd Edlinger <bernd.edlinger@hotmail.de> * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof.