Fix auto-load 7.7 regression,
the regression affects any loading from /usr/share/gdb/auto-load .
5b2bf9471f is the first bad commit
commit 5b2bf9471f
Author: Doug Evans <xdje42@gmail.com>
Date: Fri Nov 29 21:29:26 2013 -0800
Move .debug_gdb_script processing to auto-load.c.
Simplify handling of auto-loaded objfile scripts.
Fedora 20 x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done.
done.
(gdb) _
Fedora Rawhide x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done.
done.
warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path'
set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
line to your configuration file "/home/jkratoch/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/jkratoch/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) _
That is it tries to load "forbidden"
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
but it should load instead
/usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py*
Although that is also not exactly this way, there does not exist any
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
despite regressed GDB says so.
gdb/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* auto-load.c (auto_load_objfile_script_1): Change filename to
debugfile.
gdb/testsuite/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* gdb.base/auto-load-script: New file.
* gdb.base/auto-load.c: New file.
* gdb.base/auto-load.exp: New file.
Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
We currently support version of vcvtps2ph with sae and only 1 register operand.
This version is encoded as if missing operand was equal to ymm0.
I didn't found any references to this variant in
http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
This patch removes it.
opcodes/
* i386-opc.tbl: Remove wrong variant of vcvtps2ph
* i386-tbl.h: Regenerate.
ia64-linux-nat.c no longer compiles because ia64_linux_xfer_partial
no longer matches the to_xfer_partial prototype. This patch fixes
the problem by adjusting it accordingly.
gdb/ChangeLog:
* ia64-linux-nat.c (ia64_linux_xfer_partial): Add function
documentation. Adjust prototype to match the target_ops
to_xfer_partial method. Adjust implementation accordingly.
This patch changes rl78-tdep.c so that a 16-bit type is used for
register pairs instead of a pointer type as was previously the case.
This will cause these register pairs to be displayed as integers
instead of as a data address with a 0xf0000 ORed in.
E.g. registers ax, bc, de, and hl might now be displayed like this:
(gdb) info registers ax bc de hl
ax 0x6 6
bc 0x0 0
de 0x10c3 4291
hl 0x108d 423
Whereas, before, they were displayed as follows:
(gdb) info registers ax bc de hl
ax 0xf0006 0xf0006
bc 0xf0000 0xf0000
de 0xf10c3 0xf10c3
hl 0xf108d 0xf108d
These pairs are 16 bit quantities and should be displayed as such.
This change also affects the way that the banked register pairs are
displayed. Within GDB, the banked register pairs are named bank0_rp0,
bank0_rp1, .., bank3_rp2, bank3_rp3.
However, these register pairs need to be used as addresses in DWARF
expressions. I have added 16 pseudo registers corresponding to banked
register pairs. These new pseudo registers are all hidden from the
user and have a pointer type. Values from these registers are
intended to be used in DWARF expressions. Therefore,
rl78_dwarf_reg_to_regnum() has been adjusted to return these new
pseudo register numbers.
I had a much simpler patch which only changed the types, but it showed
a number of regressions due to integer values from the banked register
pairs being used as part of an address expression. This current patch
shows no regressions and now displays values of register pairs
correctly.
* rl78-tdep.c ( RL78_BANK0_RP0_PTR_REGNUM, RL78_BANK0_RP1_PTR_REGNUM)
(RL78_BANK0_RP2_PTR_REGNUM, RL78_BANK0_RP3_PTR_REGNUM)
(RL78_BANK1_RP0_PTR_REGNUM, RL78_BANK1_RP1_PTR_REGNUM)
(RL78_BANK1_RP2_PTR_REGNUM, RL78_BANK1_RP3_PTR_REGNUM)
(RL78_BANK2_RP0_PTR_REGNUM, RL78_BANK2_RP1_PTR_REGNUM)
(RL78_BANK2_RP2_PTR_REGNUM, RL78_BANK2_RP3_PTR_REGNUM)
(RL78_BANK3_RP0_PTR_REGNUM, RL78_BANK3_RP1_PTR_REGNUM)
(RL78_BANK3_RP2_PTR_REGNUM, RL78_BANK3_RP3_PTR_REGNUM):
New constants.
(rl78_register_type): Use a data pointer type for SP and
new pseudo registers mentioned above. Use a 16 bit integer
type for all other register pairs.
(rl78_register_name, rl78_g10_register_name): Update for
new pseudo registers.
(rl78_pseudo_register_read): Likewise.
(rl78_pseudo_register_write): Likewise.
(rl78_dwarf_reg_to_regnum): Return register numbers representing
to the newly added pseudo registers.
This removes yet another instance of a deprecated_xfer_memory user,
and fixes a nasty regression as a side-effect:
(gdb) start
Temporary breakpoint 1 at 0x19070: file simple_main.adb, line 4.
Starting program: /[...]/simple_main
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x19070
Cannot insert breakpoint -3.
Temporarily disabling shared library breakpoints:
breakpoint #-3
The regression was introduced by the to_xfer_partial transition
to return a status enum. procfs_xfer_partial was updated but
not the case where object is TARGET_OBJECT_MEMORY. As result,
procfs_xfer_partial was returning the length xfered rather than
the status, and the xfered buffer was left uninitialized.
gdb/
2014-02-19 Pedro Alves <palves@redhat.com>
* procfs.c (procfs_target): Don't install procfs_xfer_memory as
deprecated_xfer_memory hook.
(procfs_xfer_partial): Call procfs_xfer_memory instead
of the deprecated_xfer_memory target hook.
(procfs_xfer_memory): Adjust interface as a to_xfer_partial
helper.
A GDB internal error is found on native mingw32 target.
(gdb) run
../../binutils-gdb/gdb/target.c:1483: internal-error:
target_xfer_partial: Assertion `*xfered_len > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This error was introduced by the following snippet in commit
9b409511d0
> @@ -2536,27 +2538,30 @@ windows_xfer_shared_libraries (struct target_ops *ops,
> }
>
> obstack_free (&obstack, NULL);
> - return len;
> + *xfered_len = (ULONGEST) len;
> + return TARGET_XFER_OK;
> }
In the original code, len is returned, which could be 0, but after that
commit, only TARGET_XFER_OK is returned, which is wrong. If len is 0,
TARGET_XFER_EOF should be returned. (it is 0 in enum
target_xfer_status declaration).
gdb:
2014-02-24 Yuanhui Zhang <asmwarrior@gmail.com>
* windows-nat.c (windows_xfer_shared_libraries): Return
TARGET_XFER_EOF if LEN is zero to fix an assert failure when
requested object is TARGET_OBJECT_LIBRARIES.
Nowadays, TARGET_XFER_E_UNAVAILABLE isn't regarded as an error in
to_xfer_partial interface, so _E_ looks odd. This patch is to
replace TARGET_XFER_E_UNAVAILABLE with TARGET_XFER_UNAVAILABLE,
and change its value from -2 to 2. Since there is no comparison
on the value of 'enum target_xfer_status', so it should be safe.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_status)
<TARGET_XFER_E_UNAVAILABLE>: Rename it to ...
<TARGET_XFER_UNAVAILABLE>: ... it with setting value 2
explicitly. New.
* corefile.c (memory_error_message): User updated.
* exec.c (section_table_read_available_memory): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* target.c (target_xfer_status_to_string): Likewise.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1, target_xfer_partial): Likewise.
* valops.c (read_value_memory): Likewise.
* exec.h: Update comments.
This patch tweaks target_xfer_status_to_string on comments and argument
name.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* target.c (target_xfer_status_to_string): Rename argument err
to status.
* target.h (target_xfer_status_to_string): Update declaration.
Replace target_xfer_error_to_string with
target_xfer_status_to_string in comment.
When I build mips native gdb today, I get the follow error,
../../../git/gdb/mips-linux-nat.c: In function '_initialize_mips_linux_nat':
../../../git/gdb/mips-linux-nat.c:792:15: error: assignment from incompatible pointer type [-Werror]
cc1: all warnings being treated as errors
It looks an oversight of recent target_ops delegation patches. This
patch is to fix the build error.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* mips-linux-nat.c (super_close): Update its type.
(mips_linux_close): Pass 'self' to super_close.
This patch removes macro TARGET_XFER_STATUS_ERROR_P, as Pedro pointed
out during patches review that TARGET_XFER_STATUS_ERROR_P tends to
be unnecessary.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* target.h (TARGET_XFER_STATUS_ERROR_P): Remove.
* corefile.c (read_memory): Adjusted.
* target.c (target_write_with_progress): Adjusted.
As we migrate to the new to_xfer_partial interface, some of previous
tweaks become unnecessary, we don't have to check traceframe is
selected in each target implementation, so this patch below is
reverted.
[PATCH] Send qXfer:traceframe-info:read when traceframe is selected.
https://sourceware.org/ml/gdb-patches/2013-10/msg00752.html
Third, to_traceframe_info is only called when traceframe is selected,
that means it is only called when target is remote, tfile or ctf, so
this patch can be partially reverted,
https://sourceware.org/ml/gdb-patches/2013-04/msg00000.html
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
Revert two patches:
2013-10-25 Yao Qi <yao@codesourcery.com>
* remote.c (remote_traceframe_info): Return early if
traceframe is not selected.
2013-07-19 Yao Qi <yao@codesourcery.com>
* target.c (update_current_target): Change the default action
of 'to_traceframe_info' from tcomplain to return_zero.
* target.h (struct target_ops) <to_traceframe_info>: Add more
comments.
As the new to_xfer_partial implementations are done in ctf and tfile
targets, read_value_memory can be simplified a lot. Call
target_xfer_partial in a loop, check return value, and set bytes
unavailable when necessary.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* valops.c (read_value_memory): Rewrite it. Call
target_xfer_partial in a loop.
* exec.h (section_table_available_memory): Remove declaration.
Move comments to ...
* exec.c (section_table_available_memory): ... here. Make it static.
This patch adjust both ctf and tfile target implementation of to_xfer_partial,
to return TARGET_XFER_E_UNAVAILABLE and set *XFERED_LEN if data is
unavailable. Note that some code on xfer in exec.c can be shared, but
we can do it in a separate pass later.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* exec.c (section_table_read_available_memory): New function.
* exec.h (section_table_read_available_memory): Declare.
* ctf.c (ctf_xfer_partial): Call
section_table_read_available_memory.
* tracefile-tfile.c (tfile_xfer_partial): Likewise.
In the to_xfer_partial implementations of ctf and tfile, the code on
reading from read-only sections is duplicated. This patch moves it to
a separate function exec_read_partial_read_only.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* ctf.c (ctf_xfer_partial): Move code to ...
* exec.c (exec_read_partial_read_only): ... it. New function.
* tracefile-tfile.c (tfile_xfer_partial): Likewise.
* tracefile.c: Include "exec.h".
* exec.h (exec_read_partial_read_only): Declare.
At present, tfile target thinks it has memory but ctf doesn't.
This is an oversight when I added ctf target support. This patch
moves the implementations of to_has_all_memory and to_has_memory to
upper layer. After this change, both tfile and ctf target think
they have memory.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* tracefile-tfile.c (tfile_has_all_memory): Remove.
(tfile_has_memory): Remove.
(init_tfile_ops): Don't set fields to_has_all_memory and
to_has_memory of tfile_ops.
* tracefile.c (tracefile_has_all_memory): New function.
(tracefile_has_memory): New function.
(init_tracefile_ops): Initialize fields to_has_all_memory and
to_has_memory of 'ops'.
This patch move the duplicated code between tfile and ctf
targets into file tracefile.c. The common part of target_ops
fields are set in init_tracefile_ops.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* ctf.c (ctf_has_stack, ctf_has_registers): Remove.
(ctf_thread_alive, ctf_get_trace_status): Remove.
(init_ctf_ops): Don't set some fields of ctf_ops. Call
init_tracefile_ops.
* tracefile-tfile.c (tfile_get_trace_status): Remove.
(tfile_has_stack, tfile_has_registers): Remove.
(tfile_thread_alive): Remove.
(init_tfile_ops): Don't set some fields of tfile_ops. Call
init_tracefile_ops.
* tracefile.c (tracefile_has_stack): New function.
(tracefile_has_registers): New function.
(tracefile_thread_alive): New function.
(tracefile_get_trace_status): New function.
(init_tracefile_ops): New function.
* tracefile.h (init_tracefile_ops): Declare.
This patch is a refactor which moves trace file writer related code
out of tracepoint.c, which has 6k LOC. It moves general trace file
writer to a new file tracefile.c and moves tfile specific writer to
tracefile-tfile.c.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* Makefile.in (REMOTE_OBS): Append tracefile.o and
tracefile-tfile.o.
(HFILES_NO_SRCDIR): Add tracefile.h.
* ctf.c: Include "tracefile.h".
* tracefile.h: New file.
* tracefile.c: New file
* tracefile-tfile.c: New file.
* tracepoint.c: Include "tracefile.h".
(free_uploaded_tps, free_uploaded_tsvs): Remove declarations.
(stop_reason_names): Add const.
(trace_file_writer_xfree): Move it to tracefile.c.
(trace_save, trace_save_command, trace_save_tfile): Likewise.
(trace_save_ctf): Likewise.
(struct tfile_trace_file_writer): Move it to tracefile-tfile.c.
(tfile_target_save, tfile_dtor, tfile_start): Likewise.
(tfile_write_header, tfile_write_regblock_type): Likewise.
(tfile_write_status, tfile_write_uploaded_tsv): Likewise.
(tfile_write_uploaded_tp, tfile_write_definition_end): Likewise.
(tfile_write_raw_data, tfile_end): Likewise.
(tfile_trace_file_writer_new): Likewise.
(free_uploaded_tp): Make it extern.
(free_uploaded_tsv): Make it extern.
(_initialize_tracepoint): Move code to register command 'tsave'
to tracefile.c.
* tracepoint.h (stop_reason_names): Declare.
(struct trace_frame_write_ops): Move it to tracefile.h.
(struct trace_file_write_ops): Likewise.
(struct trace_file_writer): Likewise.
(free_uploaded_tsvs, free_uploaded_tps): Declare.
info os processes -fsanitize=address error
https://sourceware.org/bugzilla/show_bug.cgi?id=16594
info os processes
=================================================================
==5795== ERROR: AddressSanitizer: heap-use-after-free on address
0x600600214974 at pc 0x757a92 bp 0x7fff95dd9f00 sp 0x7fff95dd9ef0
READ of size 4 at 0x600600214974 thread T0
#0 0x757a91 in get_cores_used_by_process (.../gdb/gdb+0x757a91)
At least Fedora 20 has process(es):
6678 ? Ss 0:00 /usr/lib/systemd/systemd --user
6680 ? S 0:00 \_ (sd-pam)
and GDB "info os processes" crashes on it as /proc/6680/stat contains:
6680 ((sd-pam)) S 6678 6678 6678 0 -1 1077961024 33 0 0 0 0 0 0 0 20 0 1 0 18568 73768960 120 18446744073709551615 1 1
0 0 0 0 0 4096 0 18446744073709551615 0 0 17 6 0 0 0 0 0 0 0 0 0 0 0 0 0
and GDB fails to find the proper end of the process name "((sd-pam))".
Therefore it reads core number off-by-one (it reads 17 instead of 6) and
overruns the array.
(1) Make the process name parsing more foolproof.
(2) Do not trust the parsed number from /proc/PID/stat and verify it against
the array size.
I noticed that 'ps' gets this right, so I've peeked at its
sources, and it just looks for the first ')' starting at
the end.
dc072aced7:proc/readproc.c
Look for stat2proc.
Given ps does that, I believe the kernel won't ever be changed
in a way that would break it. So it sounds like could do strrchr
from the end of stat just as well without worry, which is simpler.
gdb/
2014-02-21 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16594
* common/linux-osdata.c (linux_common_core_of_thread): Find the end of
process name.
(get_cores_used_by_process): New parameter num_cores, use it.
(linux_xfer_osdata_processes): Pass num_cores to it.
* linux-tdep.c (linux_info_proc, linux_fill_prpsinfo): Find the end of
process name.
Message-ID: <20140217212826.GA15080@host2.jankratochvil.net>
The patch "return target_xfer_status in to_xfer_partial" caused a
regression in various s390(x) test cases, because memory_xfer_partial
filled only the first byte of the read buffer from a breakpoint shadow:
https://sourceware.org/ml/gdb-patches/2014-01/msg01071.html
This patch fixes the regression.
I realized that the name of this test only made sense when considering
the old (never committed) implementation of the fix that came along
with the test originally, that forced a schedlock while a step-resume
(to get over the signal handler) was inserted. The final solution
that went into the tree does not force that locking.
So this renames it to something more descriptive.
gdb/testsuite/
2014-02-21 Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.c: ... this.
* gdb.threads/step-after-sr-lock.exp: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
... this.
I was running this by hand to test out --ppc476-workaround. Another
bootstrap test doesn't take all that long, so let's add it to the
testsuite.
* ld-bootstrap/bootstrap.exp: Add ppc476 workaround test.
* ld-bootstrap/ppc476.t: New file.
This is the continuation of what Joel proposed on:
<https://sourceware.org/ml/gdb-patches/2013-12/msg00977.html>
Now that I have already submitted and pushed the patch to split
i386_stap_parse_special_token into two smaller functions, it is indeed
simpler to understand this patch.
It occurs because, on x86, triplet displacement operands are allowed
(like "-4+8-20(%rbp)"), and the current parser for this expression is
buggy. It does not correctly extract the register name from the
expression, which leads to incorrect evaluation. The parser was also
being very "generous" with the expression, so I included a few more
checks to ensure that we're indeed dealing with a triplet displacement
operand.
This patch also includes testcases for the two different kind of
expressions that can be encountered on x86: the triplet displacement
(explained above) and the three-argument displacement (as in
"(%rbx,%ebx,-8)"). The tests are obviously arch-dependent and are
placed under gdb.arch/.
Message-ID: <m3mwj1j12v.fsf@redhat.com>
URL: <https://sourceware.org/ml/gdb-patches/2014-01/msg00310.html>
gdb/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* i386-tdep.c (i386_stap_parse_special_token_triplet): Check if a
number comes after the + or - signs. Adjust length of register
name to be extracted.
gdb/testsuite/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* gdb.arch/amd64-stap-special-operands.exp: New file.
* gdb.arch/amd64-stap-three-arg-disp.S: Likewise.
* gdb.arch/amd64-stap-three-arg-disp.c: Likewise.
* gdb.arch/amd64-stap-triplet.S: Likewise.
* gdb.arch/amd64-stap-triplet.c: Likewise.
The AIX linker pointed out that gdb had multiple definitions of the
various *_varobj_ops objects. This patch fixes the problem by marking
the declarations as "extern" in varobj.h. Tested by rebuilding on
x86-64 Fedora 18 and on AIX.
2014-02-20 Tom Tromey <tromey@redhat.com>
* varobj.h (c_varobj_ops, cplus_varobj_ops, java_varobj_ops)
(ada_varobj_ops): Mark "extern".
I happened to notice that last_o_file_start is write-only in
read_dbx_symtab. This patch removes it. Tested by rebuilding.
2014-02-20 Tom Tromey <tromey@redhat.com>
* dbxread.c (read_dbx_symtab): Remove last_o_file_start.
The arm-elf assembler chokes on the extra parameters in the .section
pseudo-op, so this patch removes them.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-icycle.S: Remove second and third parameters
in .section pseudo-op.
* dwarf2read.c (struct die_info): New member in_process.
(reset_die_in_process): New function.
(process_die): Set it at the start, reset when returning.
(inherit_abstract_dies): Only call process_die if origin_child_die
not already being processed.
testsuite/
* gdb.dwarf2/dw2-icycle.S: New file.
* gdb.dwarf2/dw2-icycle.c: New file.
* gdb.dwarf2/dw2-icycle.exp: New file.
This patch brings back a comment that got stripped down a bit too much
during a recent change.
gdb/ChangeLog:
* windows-nat.c (handle_unload_dll): Add function documentation.
(do_initial_windows_stuff): Add comment explaining why we wait
until after inferior initialization has finished before
processing all DLLs.
Now that get_module_name is no longer called for handling DLL events,
we can simplify it a bit, knowing that the only use is to get the
executable's filename.
While doing so, we adjusted the implementation a bit to avoid
references to DLLs, renamed it to make its more-targeted usage
more explicit, moved it right before the only function that uses it.
We also remove the use of hard-coded length for the buffers being
used.
gdb/ChangeLog:
* windows-nat.c (get_module_name): Delete.
(windows_get_exec_module_filename): New function, mostly
inspired from get_module_name.
(windows_pid_to_exec_file): Replace call to get_module_name
by call to windows_get_exec_module_filename.
When a DLL gets loaded an the debugger gets a debug event about it,
the currently implementation in handle_load_dll currently tries to
fetch the DLL's name by first iterating over all DLLs known to
the system. It should be sufficient to rely on the name provided
with the event, however, especially in the situation we are now,
where we now know that we're past the statup phase for our inferior.
This patch therefore simplifies windows-nat.c::handle_load_dll to
only rely on the event's lpImageName.
It also updates the function's comment to document the assumption
regarding not being during the inferior's startup phase. And while
at it, it fixes the function documentation, which was probably
unintentionally inherited from another function (perhaps windows_wait).
gdb/ChangeLog:
* windows-nat.c (handle_load_dll): Rewrite this function's
introductory comment. Remove code using get_module_name
to get the DLL's name.
This patch aims at simplifying DLL handling during the inferior
initialization (process creation during the "run", or during an
"attach"). Instead of processing each DLL load event, which is
sometimes incomplete, we ignore these events until the inferior
has completed its startup phase, and then just iterate over all
DLLs via EnumProcessModules.
gdb/ChangeLog:
* windows-nat.c (get_windows_debug_event): Ignore
LOAD_DLL_DEBUG_EVENT and UNLOAD_DLL_DEBUG_EVENT
if windows_initialization_done == 0.
(windows_add_all_dlls): Renames windows_ensure_ntdll_loaded.
Adjust implementation to always load all DLLs.
(do_initial_windows_stuff): Replace call to
windows_ensure_ntdll_loaded by call to windows_add_all_dlls.
The "dll-symbols" command, specific to native Windows platforms,
gives the impression that the symbols were not loaded, first
because it completes silently, and second because the "info shared"
output does not get updated after the command completes:
(gdb) dll-symbols C:\WINDOWS\syswow64\rpcrt4.dll
(gdb) info shared
From To Syms Read Shared Object Library
[...]
0x77e51000 0x77ee2554 No C:\WINDOWS\system32\rpcrt4.dll
(we exected the "Syms Read" column to read "Yes").
As far as I can tell, the symbols actually do get loaded, but completely
independently from the solib framework, which explains the silent
loading and the fact that the "Syms Read" column does not get updated.
See windows-nat.c::safe_symbol_file_add_stub, which calls symbol_file_add
instead of calling solib_add.
But, aside from the fact that the "Syms Read" status does not get
updated, I also noticed that it does not take into account the DLL's
actual load address when loading its symbols. As a result, I believe
that we get it wrong if the DLL does not get loaded at the prefered
address.
Rather than trying to fix this command, there does not seem to be
a reason other than historical for having Windows-specific commands
which essentially re-implements the "sharedlibrary" command. The
command interface is slightly different (the latter takes a regexp
rather than a plain filename), but it should be just as easy to use
the "sharedlibrary" command, or its "share" alias, as usisng the
"dll-symbols" command. For instance:
(gdb) share rpcrt4.dll
Reading symbols from C:\WINDOWS\system32\rpcrt4.dll...(no debugging symbols found)...done.
Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
(gdb) info shared
From To Syms Read Shared Object Library
[...]
0x77e51000 0x77ee2554 Yes (*) C:\WINDOWS\system32\rpcrt4.dll
This patch therefore deprecates the "dll-symbols" command, as well
as its two aliases "add-shared-symbol-files" and "assf", with a view
of deleting them as soon as the 7.8 branch gets cut.
gdb/ChangeLog:
* windows-nat.c (_initialize_windows_nat): Deprecate the
"dll-symbols" command. Turn the "add-shared-symbol-files"
and "assf" aliases into commands, and deprecate them as well.
* NEWS: Add entry explaining that "dll-symbols" and its two
aliases are now deprecated.
gdb/doc/ChangeLog:
* gdb.texinfo (Files): Document "add-shared-symbol-files"
and "assf" as being deprecated.
(Cygwin Native): Likewise for "dll-symbols".
(Non-debug DLL Symbols): Remove reference to "dll-symbols"
as a way to force the loading of symbols from a DLL.
