I think this is safer than leaving an input_statement added during
open_input_bfds off the list. There are a number of places that
fiddle with various lists and might be confused by an off-list
statement, eg. orphan handling.
* ldlang.c (new_afile): Remove add_to_list parameter.
(lang_add_input_file): Update new_afile calls.
(lookup_name): Splice input_statement added by new_afile into
statement_list after current input_file_chain entry.
(lang_process): Update comment.
This commit:
commit aa17805fb9
Date: Sat Aug 31 23:44:40 2019 +0100
gdb: Have 'maint info sections' print all sections again
introduced a use of log10 that took an int as a parameter.
Unfortunately this was causing a compilation error on Solaris, see:
https://sourceware.org/ml/gdb-patches/2019-09/msg00230.htmlhttps://sourceware.org/ml/gdb-patches/2019-09/msg00231.html
because there was only a float, double, or long double version of
log10, and the compiler doesn't know which to choose.
This commit should resolve this issue by casting the argument to
float.
gdb/ChangeLog:
* maint.c (maint_print_section_data::maint_print_section_data):
Force use of 'float log10 (float)' by casting the argument to
float.
Make use of exec_has_index_section library function rather than
manually checking in the 'maintenance info sections' output. Should
make no difference to the test results, just makes the code easier to
read.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Use exec_has_index_section.
In this commit:
commit 6eac171f06
Date: Fri Aug 16 00:25:14 2019 +0200
[gdb] Make maint info sections print relocated addresses
A couple of things broke with the 'maintenance info sections' command,
here is some before output:
(gdb) maintenance info sections
Exec file:
`/path/to/gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
[0] 0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
[1] 0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
[2] 0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
[3] 0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
[4] 0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
[5] 0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
[6] 0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
[7] 0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
[8] 0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
[9] 0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
[10] 0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
[11] 0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
[12] 0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
[13] 0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
[14] 0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
[15] 0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
[16] 0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
[17] 0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
[18] 0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
[19] 0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
[20] 0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
[21] 0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
[22] 0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
[23] 0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
[24] 0x00000000->0x0000002c at 0x0000103c: .comment READONLY HAS_CONTENTS
[25] 0x00000000->0x00000060 at 0x00001068: .debug_aranges READONLY HAS_CONTENTS
[26] 0x00000000->0x0000061b at 0x000010c8: .debug_info READONLY HAS_CONTENTS
[27] 0x00000000->0x00000264 at 0x000016e3: .debug_abbrev READONLY HAS_CONTENTS
[28] 0x00000000->0x000001e6 at 0x00001947: .debug_line READONLY HAS_CONTENTS
[29] 0x00000000->0x00000487 at 0x00001b2d: .debug_str READONLY HAS_CONTENTS
(gdb)
And here is the output after the above commit:
(gdb) maintenance info sections
+maintenance info sections
Exec file:
`/path/to/gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
0x00000000->0x00000000 at 0x00000000: *COM* IS_COMMON
0x00000000->0x00000000 at 0x00000000: *UND*
0x00000000->0x00000000 at 0x00000000: *ABS*
0x00000000->0x00000000 at 0x00000000: *IND*
(gdb)
We lost the section index numbers, but more importantly, we lost the
information about the .debug* sections. We also gained entries for
the "fake" sections *COM*, *UND*, *ABS*, and *IND*.
I noticed this when running:
make check-gdb RUNTESTFLAGS="--target_board=cc-with-gdb-index gdb.base/maint.exp"
As this test relies on looking in the 'maint info sections' output to
see if we have a .debug_names or .gdb_index section, and these are
debug sections so they no longer show up in the 'main info sections'
output, the gdb.base/maint.exp test fails.
This commit restores the old behaviour while keeping the important
change that the above commit introduced, the addresses printed for
sections are the relocated addresses where appropriate. The above
commit mentions using this test:
make check-gdb RUNTESTFLAGS="CFLAGS_FOR_TARGET='-pie' gdb.base/compare-sections.exp"
And this still passes after this commit.
The output for 'maint info sections' now looks like this:
(gdb) maintenance info sections
Exec file:
`/home/andrew/projects/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
[0] 0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
[1] 0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
[2] 0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
[3] 0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
[4] 0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
[5] 0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
[6] 0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
[7] 0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
[8] 0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
[9] 0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
[10] 0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
[11] 0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
[12] 0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
[13] 0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
[14] 0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
[15] 0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
[16] 0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
[17] 0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
[18] 0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
[19] 0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
[20] 0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
[21] 0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
[22] 0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
[23] 0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
[24] 0x00000000->0x0000002c at 0x0000103c: .comment READONLY HAS_CONTENTS
[25] 0x00000000->0x00000060 at 0x00001068: .debug_aranges READONLY HAS_CONTENTS
[26] 0x00000000->0x0000061b at 0x000010c8: .debug_info READONLY HAS_CONTENTS
[27] 0x00000000->0x00000264 at 0x000016e3: .debug_abbrev READONLY HAS_CONTENTS
[28] 0x00000000->0x000001e6 at 0x00001947: .debug_line READONLY HAS_CONTENTS
[29] 0x00000000->0x00000487 at 0x00001b2d: .debug_str READONLY HAS_CONTENTS
(gdb)
This is basically as it was before, except that the index numbers are
now padded so the section information all lines up.
When GDB has relocated a section then the relocated addresses will be
printed, otherwise the non-relocated addresses from the bfd will be
printed.
I've added a test to gdb.base/maint.exp to do some basic validation of
the output format.
gdb/ChangeLog:
* maint.c: Add 'cmath' include.
(struct maint_print_section_data): New structure.
(print_section_index): New function.
(print_bfd_section_info): Add header comment, small whitespace
cleanup, and update to call new print_section_index function.
(print_objfile_section_info): Likewise.
(maint_obj_section_from_bfd_section): New function.
(print_bfd_section_info_maybe_relocated): New function.
(maintenance_info_sections): Add header comment, always use
bfd_map_over_sections instead of ALL_OBJFILE_OSECTIONS.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Add test for 'maint info sections'.
I found that these tests:
make check-gdb RUNTESTFLAGS="--target_board=cc-with-gdb-index gdb.base/maint.exp"
make check-gdb RUNTESTFLAGS="--target_board=cc-with-debug-names gdb.base/maint.exp"
were causing GDB to segfault. It turns out that this test runs this
command:
maint print psymbols -pc main /path/to/some/file
which tries to lookup the partial_symtab for 'main'. The problem is
that there is no partial_symtab for 'main' as we are using the
.gdb_index or .debug_names instead of partial_symtabs.
What happens is that maintenance_print_symbols calls
find_pc_sect_psymtab, which looks for the partial_symtab in the
objfile's objfile->partial_symtabs->psymtabs_addrmap.
This is a problem because when we are using the indexes
psymtabs_addrmap is reused to hold things other than partial_symtabs,
this can be seen in dwarf2read.c in create_addrmap_from_index and
create_addrmap_from_aranges. If we then lookup in psymtabs_addrmap we
end up returning a pointer to something that isn't really a
partial_symtab, after which everything goes wrong.
Initially I simply added a check at the start of find_pc_sect_psymtab
that the objfile had some partial_symtabs, like:
if (objfile->partial_symtabs->psymtabs == NULL)
return NULL;
Figuring that if there were no partial_symtabs at all then this
function should always return NULL, however, this caused a failure in
the test gdb.python/py-event.exp which I didn't dig into too deeply,
but seems to be that in this tests there are initially no psymtabs,
but the second part of find_pc_sect_psymtab does manage to read some
in from somewhere, with the check I added the test fails as we
returned NULL here and this caused GDB to load in the full symtabs
earlier than was expected.
Instead I chose to guard only the access to psymtabs_addrmap with a
check that the function has some psymtabs. This allows my original
tests to pass, and the py-event.exp test to pass too.
Now, a good argument can be made that we simply should never call
find_pc_sect_psymtab on an objfile that is using indexes instead of
partial_symtabs. I did consider this approach, we could easily add an
assert into find_pc_sect_psymtab that if we find a partial_symtab in
psymtabs_addrmap then the psymtabs pointer must be non-null. The
responsibility would then be on the user of find_pc_sect_psymtab to
ensure that the objfile being checked is suitable. In the end I
didn't take this approach as the check in find_pc_sect_psymtab is
cheap and this ensures that any future miss-uses of the function will
not cause problems.
I also extended the comment on psymtabs_addrmap to indicate that it
holds more than just partial_symtabs as this was not at all clear from
the original comment, and caused me some confusion when I was
initially debugging this problem.
gdb/ChangeLog:
* psymtab.c (find_pc_sect_psymtab): Move baseaddr local into more
inner scope, add check that the objfile has psymtabs before
checking psymtabs_addrmap.
* psymtab.h (psymtab_storage) <psymtabs_addrmap>: Extend comment.
The test-case gdb.base/store.exp fails with gcc 7.4.0:
...
nr of unexpected failures 27
...
The first FAIL:
...
110 l = add_float (l, r);
(gdb) PASS: gdb.base/store.exp: continue to wack_float
print l
$21 = <optimized out>
FAIL: gdb.base/store.exp: var float l; print old l, expecting -1
...
relates to this bit in the test-case (compiled at -O0):
...
106 float
107 wack_float (register float u, register float v)
108 {
109 register float l = u, r = v;
110 l = add_float (l, r);
111 return l + r;
112 }
...
and it expects to be able to read and modify variable l before executing line
110, but it already fails to read the value, because l has no DW_AT_location
attribute in the debug info.
Variable l is declared with the register keyword, and GCC implements the
register keyword at -O0 like so:
...
the compiler allocates distinct stack memory for all variables that do not
have the register storage-class specifier; if register is specified, the
variable may have a shorter lifespan than the code would indicate and may
never be placed in memory.
...
The fact that l has no DW_AT_location attribute, matches with the documented
"variable may have a shorter lifespan that code would indicate", (though it
is the most extreme case of it) so the gcc behaviour is valid. We can of
course improve gcc to generate better debuginfo (filed gcc PR91611), but
this not a wrong-debug problem.
[ The test-case passes with gcc 4.2.1, but for the failing test discussed
above, it passes simply because it doesn't store l in a register. ]
With the debug info missing for l, reading and setting l is unsupported, so
fix the FAIL by marking the test UNSUPPORTED instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-12 Tom de Vries <tdevries@suse.de>
* gdb.base/store.exp: Allow register variables to be optimized out at
-O0.
With this patch, we e.g. get:
[Switching to task 2 "task_list(1)"]
[Current task is 2 "task_list(1)"]
instead of
[Switching to task 2]
[Current task is 2]
The logic to produce the taskno optionally followed
by the task name has been factorized in the task_to_str function.
Task names are output between double quotes in the new messages,
similarly to what GDB does for thread names.
However, no quotes are put around task names in 'info tasks' Name column.
This was discussed with Tom, that preferred no quotes there, while I
was more in favour of visual consistency.
I discussed with a few more users, which led to (exactly) 50% preferring
quotes and 50% preferring no quotes :).
To arrive to the decision to remove the quotes, the following "killing args"
were used:
* To have quotes or to not have quotes, that is the question; yes
but not *THE* question :).
* If there is not a clear majority that prefers quotes, better to
not disturb the existing user basis for a (somewhat) irrelevant
aspect.
* The opinion of the reviewer has more weight.
So, compared to the previous version, this version remotes the quotes
in 'info tasks'.
It improves the alignement of 'info tasks' output.
With this patch, we get:
(gdb) info task
ID TID P-ID Pri State Name
* 1 555555759030 48 Runnable main_task
2 555555759e30 1 48 Selective Wait mit
(gdb)
instead of
(gdb) info task
ID TID P-ID Pri State Name
* 1 555555759030 48 Runnable main_task
2 555555759e30 1 48 Selective Wait mit
(gdb)
(e.g. the first one properly shows parent and priority under the
correct header).
This is version 4 of the 'task name' patch.
Compared to version 3, the changes are:
output task names between quotes but not in 'info tasks'
gdb/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Announce that Ada task names are now shown at more places,
and between quotes (except in info task output).
* gdb/ada-tasks.c (task_to_str): New function.
(display_current_task_id): Call task_to_str.
(task_command_1): Likewise.
(print_ada_task_info): In non-mi mode, Properly align headers and data
when task-id length is > 9 (9 is the default for a 32 bits CORE_ADDR).
gdb/doc/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Ada Tasks): Tell the task name is printed, update
examples.
gdb/testsuite/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/rdv_wait.exp: Update to new task names.
* gdb.base/task_switch_in_core.exp: Likewise.
* gdb.base/info_sources_base.c: Likewise.
For some reason, commit 906e58cab5 2008-05-15 excluded input
statements with BFD_LINKER_CREATED BFDs from being printed to map
files. This isn't ideal since it loses claimed plugin BFDs.
* ldlang.c (print_input_statement): Do not exclude linker created
BFDs.
This fixes a problem with commit 128bf1fe60, a patch I made
2019-08-06. Apparently it is possible to trigger the assertion I
added during an LTO bootstrap, something I haven't reproduced.
However, I did find a case triggered by an odd linker script feature
that allows a file to be loaded from the script without specifying
that file on the command line. Regarding input sections:
"When you use a file name which is not an archive:file specifier
and does not contain any wild card characters, the linker will
first see if you also specified the file name on the linker command
line or in an INPUT command. If you did not, the linker will
attempt to open the file as an input file, as though it appeared on
the command line."
So putting
.foo : { foo.a(*) }
into a script supposedly extracts foo.a into .foo. Except it doesn't,
since this feature is meant for object files only. Well anyway,
assuming --whole-archive was given on the command line, foo.a contains
a -flto object and no other objects involved were -flto then we'll hit
the assert due to files added like foo.a here *not* having their input
statement put on the general statement list. Why these are not put on
the statement list isn't obvious but it has been that way since commit
193c5f93a1 in 1994.
PR 24981
* ldlang.c (lang_process): Remove assertion. Comment.
It's been a long-standing nuisance that gdb reported unaligned accesses
on Solaris/SPARC as SIGSEGV, contrary to the shells and truss which
correctly report SIGBUS instead.
I could trace this down to the fault handling code in procfs.c
(procfs_target::wait): when pr_why is set to PR_FAULTED, the current
code sets the signal based on the fault number. For one, the code gets
this wrong for FLTACCESS (the unaligned access case) where it uses
SIGSEGV. What's worse, it's completely unnecessary to make up the
signal number inside gdb. Instead, it should just take what procfs
reports to avoid mismatches, which is what this patch does. I've
completely removed the explicit handling of the various fault codes: for
one, the list has already been incomplete, lacking FLTCPCOVF which
existed since at least Solaris 8. Besides, there's no reason to error
out on unknown fault codes: either the fault causes a signal which can
then be reported from procfs, or it doesn't (as for FLTPAGE) and no
reporting is necessary.
Tested on sparcv9-sun-solaris2.11 and x86_64-pc-solaris2.11. Also
spot-checked manually for a couple of cases (unaligned access, division
by 0, NULL pointer dereference).
* procfs.c (procfs_target::wait) <PR_FAULTED>: Get signal from
prstatus.pr_lwp.pr_info instead of making it up.
This simplifies memory management. I've also changed some global variables
to std::string accordingly (which store the result of these functions),
but not all because some are used with add_setshow_optional_filename_cmd
which requires a char*.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* auto-load.c (auto_load_expand_dir_vars): Update.
* defs.h (gdb_datadir): Change to std::string.
(python_libdir): Likewise.
(relocate_gdb_directory): Change return type to std::string.
* guile/guile.c (gdbscm_data_directory): Update.
(initialize_scheme_side): Update.
* jit.c (jit_reader_dir): Change to std::string.
(jit_reader_load_command): Update.
* main.c (gdb_datadir): Change to std::string.
(python_libdir): Likewise.
(set_gdb_data_directory): Update.
(relocate_path): Change to return std::string.
(relocate_gdb_directory): Change to return std::string.
(relocate_gdbinit_path_maybe_in_datadir): Update.
(captured_main_1): Update.
* python/python.c (do_start_initialization): Update.
* top.c (show_gdb_datadir): Update.
* xml-syscall.c (xml_init_syscalls_info): Update.
(init_syscalls_info): Update.
This simplifies get_init_files and makes it possible to reuse
this code in an upcoming patch for SYSTEM_GDBINIT_DIR.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* main.c (relocate_gdbinit_path_maybe_in_datadir): Factor this code
out of get_init_files.
(get_init_files): Update.
To avoid manual memory management.
Tested on buildbot.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* main.c (get_init_files): Change to use std::string.
(captured_main_1): Update.
(print_gdb_help): Update.
The code used to have undefined behaviour when template parameter is float and
host_float is NaN, because it attempted to convert NaN value to LONGEST at the
last statement. This frequently caused crashes on tests that checked "info
all-registers" (at least when the code is compiled with clang; I didn't test
with gdb).
gdb/ChangeLog:
*target-float.c (host_float_ops<T>::to_longest): Update
implementation.
This parameter is really a boolean, so change the type accordingly
and update the callers.
This is for symbol_set_names, add_psymbol_to_bcache, and
add_psymbol_to_list.
minimal_symbol_reader::record_full was already passing a bool
to symbol_set_names.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* dbxread.c (read_dbx_symtab): Update.
* dwarf2read.c (load_partial_dies): Update.
* mdebugread.c (parse_partial_symbols): Update.
(handle_psymbol_enumerators): Update.
* psympriv.h (add_psymbol_to_list): Change type of copy_names to bool.
* psymtab.c (add_psymbol_to_bcache): Likewise.
(add_psymbol_to_list): Likewise.
* symtab.c (symbol_set_names): Likewise.
* symtab.h (symbol_set_names): Likewise.
* xcoffread.c (scan_xcoff_symtab): Update.
This introduces a new bfd_set_filename function, which is then used in
various spots in gdb. This allows for the removal of some casts.
bfd/ChangeLog
2019-09-11 Tom Tromey <tom@tromey.com>
* opncls.c (bfd_set_filename): New function.
* bfd-in2.h: Regenerate.
gdb/ChangeLog
2019-09-11 Tom Tromey <tom@tromey.com>
* symfile-mem.c (symbol_file_add_from_memory): Use
bfd_set_filename.
* solib-darwin.c (darwin_bfd_open): Use bfd_set_filename.
* solib-aix.c (solib_aix_bfd_open): Use bfd_set_filename.
This constifies the argument to make_tempname and make_tempdir,
removing some casts.
I initially thought that this obsoleted the allocation in
write_archive, but write_archive closes the BFD before using the name,
so this appears not to be the case.
binutils/ChangeLog
2019-09-11 Tom Tromey <tom@tromey.com>
* objcopy.c (copy_archive): Update.
* bucomm.h (make_tempname, make_tempdir): Make argument const.
* bucomm.c (make_tempname, make_tempdir): Make argument const.
This updates the "save gdb-index" documentation to reflect the new
state of Ada support. It also corrects an existing grammatical error.
gdb/doc/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Index Files): Update Ada text.
This adds Ada support to the cc-with-tweaks.exp board file, so that we
can test Ada this way. The cc-with-tweaks.sh script already works
reasonably well as a wrapper for gnatmake.
gdb/testsuite/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* boards/cc-with-tweaks.exp: Set GNATMAKE_FOR_TARGET.
This patch adds support for Ada to .debug_names. I opted to leave
.gdb_index alone, because in my view it is a defunct format.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* dwarf-index-write.c (write_psymbols): Extend error message.
(debug_names::insert): Add Ada code.
(debug_names::write_psymbols): Remove Ada check.
(debug_names) <m_string_obstack>: New member.
* dwarf2read.c (gdb_index_symbol_name_matcher): Remove.
(gdb_index_symbol_name_matcher::matches): Remove.
(mapped_index_base::find_name_components_bounds): Add "lang"
parameter.
(mapped_index_base::build_name_components): Also split names
according to Ada syntax.
(dw2_expand_symtabs_matching_symbol): Loop over languages. Change
type of "match_callback".
(check_match, check_find_bounds_finds)
(dw2_expand_symtabs_matching): Update.
(dw2_debug_names_iterator): Add new constructor.
(dw2_debug_names_map_matching_symbols): New function.
(dw2_debug_names_expand_symtabs_matching): Update.
(dwarf2_debug_names_functions): Use
dw2_debug_names_map_matching_symbols.
An internal Ada test case showed that the .debug_names code does not
compute the same list of file names as the partial symbol reader. In
particular, the partial symbol reader uses the DW_AT_name of the CU:
/* Allocate a new partial symbol table structure. */
filename = dwarf2_string_attr (comp_unit_die, DW_AT_name, cu);
if (filename == NULL)
filename = "";
pst = create_partial_symtab (per_cu, filename);
This patch changes the .debug_names reader to follow.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dw2_get_file_names_reader): Add the
CU's file name to the results.
gdb/testsuite/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/dgopt.exp: New file.
* gdb.ada/dgopt/x.adb: New file.
This patch further simplifies the map_matching_symbols callback, by
having it take a lookup_name_info rather than a plain string.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (add_nonlocal_symbols): Combine calls to
map_matching_symbols. Update.
* dwarf2read.c (dw2_map_matching_symbols): Update.
* psymtab.c (match_partial_symbol): Change type; update.
(psym_map_matching_symbols): Likewise.
* symfile-debug.c (debug_qf_map_matching_symbols): Change
type; update.
* symfile.h (struct quick_symbol_functions)
<map_matching_symbols>: Change "name" to be a lookup_name_info.
Remove "match".
This introduces a new helper function,
iterate_over_symbols_terminated, and changes psym_map_matching_symbols
to use it. A subsequent patch will introduce a new user of this
function in the DWARF reader.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* psymtab.c (map_block): Remove.
(psym_map_matching_symbols): Use iterate_over_symbols_terminated.
* symtab.c (iterate_over_symbols_terminated): New function.
* symtab.c (iterate_over_symbols_terminated): Declare.
This changes iterate_over_symbols to return a bool. This allows it to
be reused in another context in a subsequent patch.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_iterate_over_symbols): Return bool.
* language.h (struct language_defn) <la_iterate_over_symbols>:
Return bool.
* symtab.c (iterate_over_symbols): Return bool.
* symtab.h (iterate_over_symbols): Return bool.
This changes map_matching_symbols to take a
symbol_found_callback_ftype, rather than separate callback and data
parameters. This enables a future patch to clean up some existing
code so that it can more readily be shared.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (aux_add_nonlocal_symbols): Change type.
(add_nonlocal_symbols): Update.
* dwarf2read.c (dw2_map_matching_symbols): Change type.
* psymtab.c (map_block, psym_map_matching_symbols): Change type.
* symfile-debug.c (debug_qf_map_matching_symbols): Change type.
* symfile.h (struct quick_symbol_functions) <map_matching_symbols>:
Change type of "callback". Remove "data".
This patch adds support for MVE VCTP instruction in assembler.
gas ChangeLog:
2019-09-10 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* config/tc-arm.c (M_MNEM_vctp): Add new Mnemonic.
(do_mve_vctp): Add function to encode VCTP instruction.
* testsuite/gas/arm/mve-vctp-bad.d: New test.
* testsuite/gas/arm/mve-vctp-bad.l: Likewise.
* testsuite/gas/arm/mve-vctp-bad.s: Likewise.
* testsuite/gas/arm/mve-vctp.d: Likewise.
* testsuite/gas/arm/mve-vctp.s: Likewise.
* DW_UT_skeleton and DW_UT_split_compile compilation units have dwo ids
to match the compilation unit in the skeleton and .dwo files. The dwo_id is
in the header.
Tested with CC=/usr/bin/gcc (version 8.3.0) against master branch (also with
-gsplit-dwarf and -gdwarf-4 flags) and there was no increase in the set of
tests that fails.
This is part of an effort to support DWARF 5 in gdb.
gdb/ChangeLog:
* dwarf2read.c (comp_unit_head): Update comment.
(dwarf2_dwo_name): New function declaration.
(dwarf_unit_type_name): New function declaration.
(read_comp_unit_head): Add support for new compilation units,
DW_UT_partial, DW_UT_skeleton, DW_UT_split_compile, DW_UT_split_type.
Particularly, DW_UT_skeleton and DW_UT_split_compile have dwo_id
(currently named as "signature") in their header. Also clarify error
messages.
(lookup_dwo_id): New function. Returns the dwo id of the given
compile unit.
(lookup_dwo_unit): Use the new lookup_dwo_id function.
(init_cutu_and_read_dies): Use the new dwarf2_dwo_name and lookup_dwo_id
functions.
(create_dwo_cu_reader): Use the added lookup_dwo_id function.
(dwarf2_dwo_name): Get the dwo name if present.
(dwarf_unit_type_name): Convert DW_UT_* types to string for diagnostic
purposes.
This changes the "info win" command to use ui-out. This yields
somewhat nicer table output.
gdb/ChangeLog
2019-09-09 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_all_windows_info): Use ui_out.
Valgrind reports the below leak.
Make the variable progname_copy static, so that Valgrind continues
to find a pointer to the memory given to Python.
Note that the comment in do_start_initialization and the Python documentation
indicates that the progname given to Py_SetProgramName cannot be freed.
However, in Python 3.7.4, Py_SetProgramName does:
void
Py_SetProgramName(const wchar_t *program_name)
{
...
PyMem_RawFree(_Py_path_config.program_name);
_Py_path_config.program_name = _PyMem_RawWcsdup(program_name);
So, it looks like 3.7.4 Python duplicates its argument, which explains
the leak found by Valgrind.
It looks better to respect the doc and not have GDB freeing the string
given to Py_SetProgramName, and avoid the leak error by declaring
the progname_copy static.
This will work with Python versions that really use this string without
duplicating it, and avoids a leak report for Python version that duplicates
it.
==4023== 200 bytes in 1 blocks are definitely lost in loss record 4,545 of 7,116^M
==4023== at 0x4C29F33: malloc (vg_replace_malloc.c:307)^M
==4023== by 0x446D27: xmalloc (alloc.c:60)^M
==4023== by 0x657C77: do_start_initialization (python.c:1610)^M
==4023== by 0x657C77: _initialize_python() (python.c:1823)^M
==4023== by 0x75FE24: initialize_all_files() (init.c:231)^M
==4023== by 0x708A94: gdb_init(char*) (top.c:2242)^M
==4023== by 0x5E7460: captured_main_1 (main.c:857)^M
==4023== by 0x5E7460: captured_main (main.c:1161)^M
==4023== by 0x5E7460: gdb_main(captured_main_args*) (main.c:1186)^M
==4023== by 0x4122D4: main (gdb.c:32)^M
gdb/ChangeLog
2019-09-09 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/python.c (do_start_initialization): Make progname_copy static,
to avoid a leak report.
If a TUI window has a long title, it can overflow the title line.
This changes the TUI to use just the tail part of the title in this
case.
gdb/ChangeLog
2019-09-08 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (box_win): Truncate long window titles.
gdb/testsuite/ChangeLog
2019-09-08 Tom Tromey <tom@tromey.com>
* gdb.tui/resize.exp: Remove setup_xfail.
* gdb.tui/regs.exp: Remove setup_xfail.
* gdb.tui/basic.exp: Remove setup_xfail.
The only two values valid to pass to the block_index parameter of
quick_symbol_functions::lookup_symbol are GLOBAL_BLOCK and STATIC_BLOCK,
part of enum block_enum. Change the type of that parameter to
block_enum.
Change also the block_index field of dw2_symtab_iterator in the same
way.. This makes it consistent with dw2_debug_names_iterator, which
already uses block_enum for its block_index field.
This is a follow-up to this thread:
https://sourceware.org/ml/gdb-patches/2019-08/msg00097.html
gdb/ChangeLog:
* dwarf2read.c (struct dw2_symtab_iterator) <block_index>:
Change type to gdb::optional<block_enum>.
(dw2_symtab_iter_init): Change block_index parameter type
to gdb::optional<block_enum>.
(dw2_lookup_symbol): Change block_index parameter
type to block_enum.c
(dw2_debug_names_lookup_symbol): Likewise.
* psymtab.c (psym_lookup_symbol): Likewise.
* symfile-debug.c (debug_qf_lookup_symbol): Likewise.
* symfile.h (struct quick_symbol_functions) <lookup_symbol>:
Likewise.
These parameters are only used as bools. This also
renames "flag" to "relocatable" to make it clearer
what it does.
gdb/ChangeLog:
2019-09-06 Christian Biesinger <cbiesinger@google.com>
* defs.h (relocate_gdb_directory): Change int to bool in
signature and rename flag to relocatable.
* main.c (relocate_path): Likewise.
(relocate_gdb_directory): Likewise.
GDB Administrator
Alan Modra
Andrew Burgess
Tom de Vries
Philippe Waroquiers
Rainer Orth
Christian Biesinger
Ali Tamur
Tom Tromey
Miod Vallat
Tom Tromey
Nick Clifton
Srinath Parvathaneni
H.J. Lu
Phil Blundell
Simon Marchi
David Blaikie