When compiling on Cygwin, we get:
CXX win32-low.o
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc: In function ‘int get_child_debug_event(DWORD*, target_waitstatus*)’:
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc:1459:17: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long int’ [-Werror=format=]
1459 | OUTMSG2 (("get_windows_debug_event - "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1460 | "unexpected stop in 0x%x (expecting 0x%x)\n",
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1461 | ptid.lwp (), desired_stop_thread_id));
| ~~~~~~~~~~~
| |
| long int
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc:52:11: note: in definition of macro ‘OUTMSG2’
52 | printf X; \
| ^
/home/smarchi/src/binutils-gdb/gdbserver/win32-low.cc:1460:26: note: format string is defined here
1460 | "unexpected stop in 0x%x (expecting 0x%x)\n",
| ~^
| |
| unsigned int
| %lx
`ptid.lwp ()` is a `long` value, so it indeed needs the `l` size modifier.
gdbserver/ChangeLog:
* win32-low.cc (get_child_debug_event): Fix format string warning.
While debugging a bug on Windows, I noticed that windows-nat.c is not
sending its debugging output to gdb_stdlog. This is unfortunate
because it means that "set logging debugredirect" doesn't work
properly.
This patch fixes the problem by changing windows-nat.c to use
debug_printf.
Note that get_windows_debug_event also writes one debugging message
unconditionally. It isn't clear to me if this really ought to use
DEBUG_EVENTS or not, since it seems like perhaps it is intended to
note an unexpected event occurring. So, I didn't change this.
I'm checking this in.
gdb/ChangeLog
2020-04-15 Tom Tromey <tromey@adacore.com>
* windows-nat.c (DEBUG_EXEC, DEBUG_EVENTS, DEBUG_MEM)
(DEBUG_EXCEPT): Use debug_printf.
Commit:
commit 724fd9ba43
Date: Mon Jan 27 17:37:20 2020 +0000
gdb: Restructure the completion_tracker class
caused the completion hash table to become corrupted if the table ever
needed to grow beyond its original size of 200 elements.
The hash table stores completion_tracker::completion_hash_entry
objects, but hashes them based on their name, which is only one field
of the object.
When possibly inserting a new element we compute the hash with
htab_hash_string of the new elements name, and then lookup matching
elements using htab_find_slot_with_hash. If there's not matching
element we create a completion_hash_entry object within the hash
table.
However, when we allocate the hash we pass htab_hash_string to
htab_create_alloc as the hash function, and this is not OK. This
means that when the hash table needs to grow, existing elements within
the hash are re-hashed by passing the completion_hash_entry pointer to
htab_hash_string, which obviously does not do what we expect.
The solution is to create a new hash function that takes a pointer to
a completion_hash_entry, and then calls htab_hash_string on the name
of the entry only.
This regression was spotted when running the gdb.base/completion.exp
test on the aarch64 target.
gdb/ChangeLog:
* completer.c (class completion_tracker::completion_hash_entry)
<hash_name>: New member function.
(completion_tracker::discard_completions): New callback to hash a
completion_hash_entry, pass this to htab_create_alloc.
gdb/testsuite/ChangeLog:
* gdb.base/many-completions.exp: New file.
It seems Cygwin's realpath() can fail on certain DLLs (apparently some
AV software prevent it working on it's DLLs; See [1], [2]). Warn rather
than stopping with an error if that occurs.
Based on an original patch from Tim Chick.
[1] https://cygwin.com/ml/cygwin/2014-08/msg00401.html
[2] https://cygwin.com/ml/cygwin/2015-11/msg00353.html
gdb/ChangeLog:
2016-01-20 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (windows_make_so): Warn rather than stopping with
an error if realpath() fails.
I find this useful when needing to compare compiler output, where the
address of the instruction and the value of symbols results in
unwanted differences.
* objdump.c (no_addresses): New static var.
(usage): Print help for --no-addresses.
(long_options): Add --no-addresses entry.
(objdump_print_addr_with_sym, objdump_print_addr): Omit symbol address.
(disassemble_bytes): Don't print current line address, or reloc
address.
* doc/binutils.texi: Document objdump --no-addresses.
PR 25823
* peXXigen.c (_bfd_XXi_swap_sym_in <C_SECTION>): Don't use a
pointer into strings that may be freed for section name, always
allocate a new string.
Building gdb-9.1 on a system that has an older version of makeinfo
(4.8) shows the following warnings:
-----------------
make[4]: Entering directory '/home/tester/gdb-9.1/build/gdb/doc'
makeinfo --split-size=5000000 --split-size=5000000 -I
../../../gdb/doc/../../readline/readline/doc -I ../../../gdb/doc/../mi
-I ../../../gdb/doc \
-o gdb.info ../../../gdb/doc/gdb.texinfo
../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character ] in @var.
../../../gdb/doc//python.texi:3297: warning: `.' or `,' must follow
@xref, not `A'.
make[4]: Leaving directory '/home/tester/gdb-9.1/build/gdb/doc'
-----------------
These are thrown by expressions like `@var{[host]}`, intended to
produce `[HOST]`.
In that context this should instead be changed to `[@var{host}]`, which
has the same effect but without the warnings.
As for the warning in `python.texi`, there's period missing at the end
of one `@xref{}` clause. Added.
gdb/doc/ChangeLog:
2020-04-15 Artur Shepilko <nomadbyte@gmail.com>
* gdb.texinfo: Transform @var{[host]} to [@var{host}]; this
clears makeinfo warnings.
* python.texi: Add a missing period trailing an @xref{} clause;
this clears a makeinfo warning.
When readelf is processing more than one file, static bss vars won't
start out as zero for the second file unless they are cleared.
* readelf.c (process_symbol_table): Zero gnubuckets, gnuchains
etc. after freeing.
This patch extends the relocation and line number counters for
coff-go32 and coff-go32-exe to 32 bits. As I understand it works the
same as for PE-COFF:
If the number of relocations in an object file exceeds 65534, the
NRELOC field is set to 65535 and the actual number of relocations is
stored in the VADDR field of the first relocation entry.
Executable files have no relocations, and thus the NRELOC field is
repurposed to extend NLNNO to 32-bits.
bfd * coff-go32.c (COFF_GO32, IMAGE_SCN_LNK_NRELOC_OVFL)
(coff_SWAP_scnhdr_in, coff_SWAP_scnhdr_out): Define.
(_bfd_go32_swap_scnhdr_in, _bfd_go32_swap_scnhdr_out)
(_bfd_go32_mkobject): New functions.
* coff-stgo32.c (IMAGE_SCN_LNK_NRELOC_OVFL)
(coff_SWAP_scnhdr_in, coff_SWAP_scnhdr_out): Define.
(go32exe_mkobject): Call _bfd_go32_mkobject.
* coffcode.h (COFF_WITH_EXTENDED_RELOC_COUNTER): Define.
(coff_set_alignment_hook): Define function for COFF_GO32_EXE
and COFF_GO32.
(coff_write_relocs): Enable extended reloc counter code if
COFF_WITH_EXTENDED_RELOC_COUNTER is defined. Test for obj_go32.
(coff_write_object_contents): Likewise. Pad section headers
for COFF_GO32 and COFF_GO32EXE. Use bfd_coff_swap_scnhdr_out
instead of coff_swap_scnhdr_out.
* cofflink.c (_bfd_coff_final_link): Test also for obj_go32 to
enable extended reloc counter.
* coffswap.h: (coff_swap_scnhdr_in, coff_swap_scnhdr_out):
Declare with ATTRIBUTE_UNUSED.
* libcoff-in.h: (struct coff_tdata): New field go32.
(obj_go32): Define.
* libcoff.h: Regenerate.
Output based on FreeBSD with the following changes:
- "utime+stime, children" merged from "utime, children" and
"stime, children".
- "Minor faults, children", "Major faults, children",
"Virtual memory size" removed as not available in a direct
equivalent.
No new values missing or skipped in FreeBSD are printed, although
there is a long list of potential candiates.
gdb/ChangeLog:
* nbsd-nat.c (nbsd_pid_to_kinfo_proc2): New.
(nbsd_nat_target::info_proc): Add do_status.
[ The test-case requires commit c1a66c0629 "[gdb] Expand symbolless symtabs
using maint expand-symtabs". ]
Consider the debug info for the test-case included in this patch. It consists
of a PU:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<1><d3>: Abbrev Number: 0
...
imported by a CU:
...
<0><df>: Abbrev Number: 2 (DW_TAG_compile_unit)
<e0> DW_AT_language : 2 (non-ANSI C)
<e1> DW_AT_stmt_list : 0xe9
<1><e5>: Abbrev Number: 3 (DW_TAG_imported_unit)
<e6> DW_AT_import : <0xd2> [Abbrev Number: 2]
<1><ea>: Abbrev Number: 0
...
and the CU has a dw2-symtab-includes.h file in the .debug_line file name
table:
...
The Directory Table (offset 0x101):
1 /data/gdb_versions/devel/src/gdb/testsuite/gdb.dwarf2
The File Name Table (offset 0x138):
Entry Dir Time Size Name
1 1 0 0 dw2-symtab-includes.h
...
After expanding all symtabs, we can see the CU listed in the user field of the
PU, and vice-versa the PU listed in the includes of the CU:
...
$ gdb.sh -batch \
-iex "set language c" \
outputs/gdb.dwarf2/dw2-symtab-includes/dw2-symtab-includes \
-ex "maint expand-symtabs" \
-ex "maint info symtabs"
...
{ ((struct compunit_symtab *) 0x394dd60)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x394dea0)
user ((struct compunit_symtab *) 0x394dba0)
}
{ ((struct compunit_symtab *) 0x394dba0)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x394dd10)
user ((struct compunit_symtab *) (null))
( includes
((struct compunit_symtab *) 0x394dd60)
)
}
...
But if we instead only expand the symtab for the dw2-symtab-includes.h file,
the includes and user links are gone:
...
$ gdb -batch \
-iex "set language c" \
outputs/gdb.dwarf2/dw2-symtab-includes/dw2-symtab-includes \
-ex "maint expand-symtabs dw2-symtab-includes.h" \
-ex "maint info symtabs"
...
{ ((struct compunit_symtab *) 0x2728210)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x2728350)
user ((struct compunit_symtab *) (null))
}
{ ((struct compunit_symtab *) 0x2728050)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x27281c0)
user ((struct compunit_symtab *) (null))
}
...
The includes are calculated by process_cu_includes in gdb/dwarf2/read.c.
In the case of expanding all symtabs:
- the CU partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_psymtab::read_symtab
- dwarf2_psymtab::read_symtab calls dwarf2_psymtab::expand_psymtab
- dwarf2_psymtab::read_symtab calls process_cu_includes, and we have the
includes
In the case of expanding the symtab for dw2-symtab-includes.h:
- the dw2-symtab-includes.h partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_include_psymtab::read_symtab
- dwarf2_include_psymtab::read_symtab calls
dwarf2_include_psymtab::expand_psymtab
- dwarf2_include_psymtab::expand_psymtab calls
partial_symtab::expand_dependencies
- partial_symtab::expand_dependencies calls dwarf2_psymtab::expand_psymtab
for the CU partial symtab
- the CU partial symtab is expanded using dwarf2_psymtab::expand_psymtab
- process_cu_includes is never called
Fix this by making sure in dwarf2_include_psymtab::read_symtab that
read_symtab is called for the CU partial symtab.
Tested on x86_64-linux, with native, and target board cc-with-dwz and
cc-with-dwz-m.
In addition, tested test-case with target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/ChangeLog:
2020-04-14 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/25718
* psympriv.h (struct partial_symtab::read_symtab)
(struct partial_symtab::expand_psymtab)
(struct partial_symtab::read_dependencies): Update comments.
* dwarf2/read.c (struct dwarf2_include_psymtab::read_symtab): Call
read_symtab for includer.
(struct dwarf2_include_psymtab::expand_psymtab): Assert false.
(struct dwarf2_include_psymtab::readin_p): Call readin_p () for includer.
(struct dwarf2_include_psymtab::m_readin): Remove.
(struct dwarf2_include_psymtab::includer): New member function.
(dwarf2_psymtab::expand_psymtab): Assert !readin.
gdb/testsuite/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25718
* gdb.dwarf2/dw2-symtab-includes.exp: New file.
Consider this test-case, consisting of header file hello.h:
...
inline static const char*
foo (void)
{
return "foo";
}
...
and source file hello.c:
...
int
main (void)
{
printf ("hello: %s\n", foo ());
return 0;
}
...
compiled with -g:
...
$ gcc hello.c -g
...
When trying to expand the partial symtab for hello.h:
...
$ gdb -batch \
-iex "set language c" \
a.out \
-ex "maint expand-symtabs hello.h" \
-ex "maint info psymtabs"
...
we in fact find that the partial symtab for hello.h (and corresponding
includer partial symtab hello.c) have not been expanded:
...
{ psymtab hello.h ((struct partial_symtab *) 0x27cf070)
readin no
...
{ psymtab hello.c ((struct partial_symtab *) 0x2cf09e0)
readin no
...
This is due to the recursively_search_psymtabs call in
psym_expand_symtabs_matching:
...
if (recursively_search_psymtabs (ps, objfile, domain,
lookup_name, symbol_matcher))
...
which always returns false for symbolless partial symtabs.
The same problem occurs with CUs where the dwarf is generated by gas
--gdwarf-2 for a foo.S: if we read such a test-case with -readnow, we'll have
a symbolless symtab for foo.S. But if we read the test-case with partial
symtabs, and expand those using "maint expand-symtabs", the foo.S psymtab
remains unexpanded.
Fix this by passing a NULL symbol_matcher and lookup_name to
expand_symtabs_matching in maintenance_expand_symtabs, and skipping the call
to recursively_search_psymtabs if symbol_matcher == NULL and
lookup_name == NULL.
Build and tested on x86_64-linux, with native.
In addition, tested test-case with target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25720
* symmisc.c (maintenance_expand_symtabs): Call expand_symtabs_matching
with NULL symbol_matcher and lookup_name.
* psymtab.c (psym_expand_symtabs_matching): Handle NULL symbol_matcher
and lookup_name.
* dwarf2/read.c (dw2_expand_symtabs_matching)
(dw2_debug_names_expand_symtabs_matching): Same.
* symfile.h (struct quick_symbol_functions::expand_symtabs_matching):
Make lookup_name a pointer. Update comment.
* symtab.c (global_symbol_searcher::expand_symtabs): Handle
lookup_name being a pointer.
* symfile.c (expand_symtabs_matching): Same.
* symfile-debug.c (debug_qf_expand_symtabs_matching): Same.
* linespec.c (iterate_over_all_matching_symtabs): Same.
gdb/testsuite/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25720
* gdb.base/maint-expand-symbols-header-file.c: New test.
* gdb.base/maint-expand-symbols-header-file.exp: New file.
* gdb.base/maint-expand-symbols-header-file.h: New test.
When reconstructing dynamic symbol table from the PT_DYNAMIC segment,
compute dynamic symbol table size from hash table. For DT_HASH, the
number of dynamic symbol table entries equals the number of chains.
For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols with non-STB_LOCAL
indings are in hash table. Since DT_GNU_HASH/DT_MIPS_XHASH place all
symbols with STB_LOCAL binding before symbols with other bindings and
all undefined symbols defined ones in dynamic symbol table, the highest
symbol index in DT_GNU_HASH/DT_MIPS_XHASH is the highest dynamic symbol
table index.
Rewrite print_dynamic_symbol to dump dynamic symbol table for --dyn-syms
and --syms --use-dynamic.
binutils/
PR binutils/25707
* readelf.c (nbuckets): New.
(nchains): Likewise.
(buckets): Likewise.
(chains): Likewise.
(ngnubuckets): Likewise.
(gnubuckets): Likewise.
(gnuchains): Likewise.
(mipsxlat): Likewise.
(ngnuchains): Likewise.
(gnusymidx): Likewise.
(VALID_SYMBOL_NAME): Likewise.
(VALID_DYNAMIC_NAME): Use it.
(get_dynamic_data): Moved before process_dynamic_section.
(get_num_dynamic_syms): New function.
(process_dynamic_section): Use DT_SYMTAB, DT_SYMENT, DT_HASH,
DT_GNU_HASH and DT_MIPS_XHASH to reconstruct dynamic symbol
table. Use DT_STRTAB and DT_STRSZ to reconstruct dynamic string
table.
(get_symbol_index_type): Don't print "bad section index" when
there is no section header.
(print_dynamic_symbol): Rewrite.
(process_symbol_table): Call print_dynamic_symbol to dump dynamic
symbol table.
ld/
PR binutils/25707
* testsuite/ld-arm/armthumb-lib.sym: Updated.
* testsuite/ld-arm/farcall-mixed-app.sym: Likewise.
* testsuite/ld-arm/farcall-mixed-app2.sym: Likewise.
* testsuite/ld-arm/fdpic-main-m.sym: Likewise.
* testsuite/ld-arm/fdpic-main.sym: Likewise.
* testsuite/ld-arm/fdpic-shared-m.sym: Likewise.
* testsuite/ld-arm/fdpic-shared.sym: Likewise.
* testsuite/ld-arm/mixed-app.sym: Likewise.
* testsuite/ld-arm/mixed-lib.sym: Likewise.
* testsuite/ld-arm/preempt-app.sym: Likewise.
* testsuite/ld-elf/hash.d: Likewise.
* testsuite/ld-elf/pr13195.d: Likewise.
* testsuite/ld-elfvsb/hidden2.d: Likewise.
* testsuite/ld-mips-elf/hash2.d: Likewise.
Every time I write a test making use of the DWARF assembler I end up
copying in the function get_func_info. Duplicating code is bad, so
lets put this function into lib/dwarf.exp and remove all of the
duplicates.
There should be no changes in the testsuite behaviour after this
commit.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-many-frames.exp (get_func_info): Delete.
* gdb.dwarf2/dw2-inline-small-func.exp: Pass options to
get_func_info.
(get_func_info): Delete.
* gdb.dwarf2/dw2-is-stmt-2.exp (get_func_info): Delete.
* gdb.dwarf2/dw2-is-stmt.exp (get_func_info): Delete.
* lib/dwarf.exp (get_func_info): New function.
This moves the gdb_notifier comment a bit lower in event-loop.c, to
where it belongs; and removes an obsolete comment that Pedro pointed
out.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* event-loop.c: Move comment. Remove obsolete comment.
event-loop.c requires the client to provide some functions. This
patch implements these functions for gdbserver.
gdbserver/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* server.c (invoke_async_signal_handlers)
(check_async_event_handlers, flush_streams, gdb_select): New
functions.
This patch splits out some gdb-specific code from event-loop, into new
files async-event.[ch]. Strictly speaking this code could perhaps be
put into gdbsupport/, but because gdbserver does not currently use it,
it seemed better, for size reasons, to split it out.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* tui/tui-win.c: Include async-event.h.
* remote.c: Include async-event.h.
* remote-notif.c: Include async-event.h.
* record-full.c: Include async-event.h.
* record-btrace.c: Include async-event.h.
* infrun.c: Include async-event.h.
* event-top.c: Include async-event.h.
* event-loop.h: Move some declarations to async-event.h.
* event-loop.c: Don't include ser-event.h or top.h. Move some
code to async-event.c.
* async-event.h: New file.
* async-event.c: New file.
* Makefile.in (COMMON_SFILES): Add async-event.c.
(HFILES_NO_SRCDIR): Add async-event.h.
Code in gdbsupport can't call gdb_flush, so this introduces a new
"flush_streams" function that must be supplied by the client.
Note that the similar gdb_flush_out_err exists, but it isn't defined
in quite the same way, so it wasn't clear to me whether the two could
be merged.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* utils.c (flush_streams): New function.
* event-loop.c (gdb_wait_for_event): Call flush_streams.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* errors.h (flush_streams): Declare.
Change event-loop.c to avoid printf_unfiltered in favor of warning.
warning is aleady available to code in gdbsupport/.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* event-loop.c (handle_file_event): Use warning, not
printf_unfiltered.
Include <chrono> in event-loop.c, because it is used there. Currently
it is included indirectly, but after the subsequent patches this will
no longer be the case.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* event-loop.c: Include <chrono>.
This moves gdb_select.h to gdbsupport/, so it can be used by other
code there.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* gdb_select.h: Move to ../gdbsupport/.
* event-loop.c: Update include path.
* top.c: Update include path.
* ser-base.c: Update include path.
* ui-file.c: Update include path.
* ser-tcp.c: Update include path.
* guile/scm-ports.c: Update include path.
* posix-hdep.c: Update include path.
* ser-unix.c: Update include path.
* gdb_usleep.c: Update include path.
* mingw-hdep.c: Update include path.
* inflow.c: Update include path.
* infrun.c: Update include path.
* event-top.c: Update include path.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* gdb_select.h: Move from ../gdb/.
gdb_select.h and the event loop require some configure checks, so this
moves the needed checks to common.m4 and updates the configure
scripts.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Remove checks that are now in GDB_AC_COMMON.
gdbserver/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* config.in: Rebuild.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* config.in, configure: Rebuild.
* common.m4 (GDB_AC_COMMON): Check for poll.h, sys/poll.h,
sys/select.h, and poll.
A subsequent patch is going to move event-loop.c to gdbsupport. In a
review of an earlier version of this series, Pedro pointed out that
the resulting code would be cleaner if start_event_loop were not
shared -- because gdb and gdbserver have some different needs here --
and so this moves start_event_loop to main.c. Because the only caller
is there, it is also now static.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* event-loop.h (start_event_loop): Don't declare.
* event-loop.c (start_event_loop): Move...
* main.c (start_event_loop): ...here. Now static.
When running test-case gdb.ada/catch_ex.exp using system gnatmake, gnatmake is
invoked like this:
...
Executing on host: \
gnatmake foo.adb -gnata -f -Isrc/gdb/testsuite/gdb.ada/catch_ex -g -lm \
-o outputs/gdb.ada/catch_ex/foo
...
When I try to use a more recent gnatmake, by mocking up a combined build:
...
$ ls -la build/gcc/
lrwxrwxrwx gfortran -> /usr/bin/gfortran-10
lrwxrwxrwx gnatbind -> /usr/bin/gnatbind-10
lrwxrwxrwx gnatlink -> /usr/bin/gnatlink-10
lrwxrwxrwx gnatmake -> /usr/bin/gnatmake-10
lrwxrwxrwx xg++ -> /usr/bin/g++-10
lrwxrwxrwx xgcc -> /usr/bin/gcc-10
...
gnatmake is invoked like this:
...
Executing on host: \
/data/gdb_versions/devel/build/gcc/gnatmake \
-I/data/gdb_versions/devel/build/gcc/ada/rts \
--GCC=/data/gdb_versions/devel/build/gcc/xgcc \
--GNATBIND=/data/gdb_versions/devel/build/gcc/gnatbind \
--GNATLINK=/data/gdb_versions/devel/build/gcc/gnatlink \
-cargs -B/data/gdb_versions/devel/build/gcc \
-largs --GCC=/data/gdb_versions/devel/build/gcc/xgcc \
-B/data/gdb_versions/devel/build/gcc \
-margs foo.adb -gnata -f -Isrc/gdb/testsuite/gdb.ada/catch_ex -g -lm \
-o outputs/gdb.ada/catch_ex/foo
...
This is set up by this bit in find_gnatmake in
/usr/share/dejagnu/libgloss.exp:
...
if {![is_remote host]} {
set file [lookfor_file $tool_root_dir gnatmake]
if { $file == "" } {
set file [lookfor_file $tool_root_dir gcc/gnatmake]
}
if { $file != "" } {
set root [file dirname $file]
set CC "$file -I$root/ada/rts --GCC=$root/xgcc \
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink \
-cargs -B$root \
-largs --GCC=$root/xgcc -B$root -margs"
} else {
...
However, when running test-case gdb.ada/catch_ex_std.exp using the mockup
combined build, we get:
...
Executing on host: \
/data/gdb_versions/devel/build/gcc/gnatlink foo \
-Wl,-rpath,\$ORIGIN -Wl,-lsome_package
b~foo.adb:26:79: "SS_Stack" not declared in "Secondary_Stack"^M
b~foo.adb:26:89: incorrect constraint for this kind of type^M
b~foo.adb:121:56: "Runtime_Default_Sec_Stack_Size" not declared in "Parameters"^M
FAIL: gdb.ada/catch_ex_std.exp: gnatlink foo
...
The problem is caused by the fact that the test uses gnatlink directly
rather than using gnatmake. The invoked gnatlink (which is gnatlink-10) calls
gcc-7, which are incompatible (see gcc PR86211). This problem doesn't occur
with gnatmake because there the gcc to use is passed as an argument to
gnatlink.
Fix this by adding the -largs bit from find_gnatmake in find_ada_tool, for the
case that $tool == gnatlink.
Tested on x86_64-linux, with system gcc, and gcc-10.
gdb/testsuite/ChangeLog:
2020-04-13 Tom de Vries <tdevries@suse.de>
* lib/ada.exp (find_ada_tool): Pass --GCC and -B to gnatlink, similar
to what find_gnatmake does.
Add nbsd_pid_to_cwd() to query the program current directory.
gdb/ChangeLog:
* nbsd-nat.c (nbsd_pid_to_cwd): Add.
(nbsd_nat_target::info_proc): Add do_cwd.
Define nbsd_nat_target::find_memory_regions and
nbsd_nat_target::info_proc. info_proc handles as of now only
the "mappings" command.
Define a local static function kinfo_get_vmmap() that reads
the process memory layout of a specified process.
kinfo_get_vmmap() wraps the sysctl(3) call.
nbsd-tdep.c defines now utility functions for printing the
process memory layout:
* nbsd_info_proc_mappings_header()
* nbsd_vm_map_entry_flags()
* nbsd_info_proc_mappings_entry()
gdb/ChangeLog:
* nbsd-nat.c; Include "nbsd-tdep.h" and "gdbarch.h".
* nbsd-nat.c (nbsd_nat_target::find_memory_regions)
(nbsd_nat_target::info_proc): New functions.
* nbsd-nat.c (kinfo_get_vmmap): New function.
* nbsd-nat.c (nbsd_nat_target::info_proc) Use
nbsd_info_proc_mappings_header and nbsd_info_proc_mappings_entry.
* nbsd-tdep.c (nbsd_info_proc_mappings_header)
(nbsd_info_proc_mappings_entry, nbsd_vm_map_entry_flags): New
functions.
* nbsd-tdep.c (KINFO_VME_PROT_READ, KINFO_VME_PROT_WRITE)
(KINFO_VME_PROT_EXEC, KINFO_VME_FLAG_COW)
(KINFO_VME_FLAG_NEEDS_COPY, KINFO_VME_FLAG_NOCOREDUMP)
(KINFO_VME_FLAG_PAGEABLE, KINFO_VME_FLAG_GROWS_UP)
(KINFO_VME_FLAG_GROWS_DOWN): New.
gdb version 9.1, built with clang 8.0.0 on Ubuntu 18.04 (x86_64);
--enable-ubsan (for clang's undefined behavior sanitizer)
Executing command; `maint selftest copy_bitwise` bombs in runtime error:
../../gdb/utils.c:3432:28: runtime error: left shift of negative value -1
Closer look reveals the offending shift: `(~0 << nbits)`, apparently 0
is treated as signed int, resulting in negative complement. Explicitly
stating it unsigned 0U fixes it and the `copy_bitwise` test passes
ok.
Sometimes, get_msymbol_address can cause infinite recursion, leading
to a crash. This was reported previously here:
https://sourceware.org/pipermail/gdb-patches/2019-November/162154.html
A user on irc reported this as well, and with his help and the help of
a friend of his, we found that the problem occurred because, when
reloading a separate debug objfile, the objfile would lose the
OBJF_MAINLINE flag. This would cause some symbols from this separate
debug objfile to be marked "maybe_copied" -- but then
get_msymbol_address could find the same symbol and fail as reported.
This patch fixes the bug by preserving OBJF_MAINLINE.
No test case, unfortunately, because I could not successfully make
one.
gdb/ChangeLog
2020-04-10 Tom Tromey <tromey@adacore.com>
* symfile.c (symbol_file_add_separate): Preserve OBJF_MAINLINE.
