From: Simon Marchi <simon.marchi@polymtl.ca>
To: Doug Gilmore <Doug.Gilmore@imgtec.com>
Cc: Luis Machado <lgustavo@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix PR 21337 v2: segfault when re-reading symbols with remote debugging.
Date: Fri, 12 May 2017 03:29:00 -0000 [thread overview]
Message-ID: <09492e58ce0daf1efee14636bc5312cc@polymtl.ca> (raw)
In-Reply-To: <28fcce08-cab6-1e63-80d7-1d61c688cc10@imgtec.com>
Hi Doug,
On 2017-05-10 19:26, Doug Gilmore wrote:
> The basic issue is that section data referenced through an objfile
> pointer can also be referenced via the program-space data pointer,
> although via a separate mapping mechanism, which is set up by
> update_section_map. Thus once section data attached to an objfile
> pointer is released, the section map associated with the program-space
> data pointer must be marked dirty to ensure that update_section_map is
> called to prevent stale data being referenced. For the matter at hand
> this marking is being done via a call to objfiles_changed.
>
> Before commit 3e29f34 objfiles_changed could be called after all of
> the objfile pointers were processed in reread_symbols since section
> data references via the program-space data pointer would not occur in
> the calls of read_symbols performed by reread_symbols.
>
> With commit 3e29f34 MIPS target specific calls to find_pc_section were
> added to the code for DWARF information processing, which is called
> via read_symbols. Thus in reread_symbols the call to objfiles_changed
> needs to be called before calling read_symbols, otherwise stale
> section data can be referenced.
>
> Thanks to Luis Machado for providing text for the main comment
> associated with the change.
Thanks for the commit log.
> gdb/
> 2017-??-?? Doug Gilmore <Doug.Gilmore@Doug.Gilmore@imgtec.com>
Your email address has twice the username part (in both ChangeLog
entries).
> * symfile.c (reread_symbols): Fix PR 21337.
This should state more precisely what actually changed:
* symfile.c (reread_symbols): Call objfiles_changed just before
read_symbols.
>
> gdb/testsuite
> 2017-??-?? Doug Gilmore <Doug Gilmore@rDoug.Gilmore@imgtec.com>
> PR gdb/r21337
Spurious "r" before the PR number.
> * gdb.base/pr21337.c: New file.
> * gdb.base/pr21337.exp: New file.
> * gdb.base/pr21337.gdb: New file.
> ---
> gdb/symfile.c | 20 +++++++++++--
> gdb/testsuite/gdb.base/pr21337.c | 4 +++
> gdb/testsuite/gdb.base/pr21337.exp | 57
> ++++++++++++++++++++++++++++++++++++++
> gdb/testsuite/gdb.base/pr21337.gdb | 13 +++++++++
> 4 files changed, 91 insertions(+), 3 deletions(-)
> create mode 100644 gdb/testsuite/gdb.base/pr21337.c
> create mode 100644 gdb/testsuite/gdb.base/pr21337.exp
> create mode 100644 gdb/testsuite/gdb.base/pr21337.gdb
>
> diff --git a/gdb/symfile.c b/gdb/symfile.c
> index 846aabe..0492f56 100644
> --- a/gdb/symfile.c
> +++ b/gdb/symfile.c
> @@ -2576,6 +2576,9 @@ reread_symbols (void)
> /* Free the obstacks for non-reusable objfiles. */
> psymbol_bcache_free (objfile->psymbol_cache);
> objfile->psymbol_cache = psymbol_bcache_init ();
> +
> + /* NB: after this call to obstack_free, objfiles_changed
> + will need to be called (see discussion below). */
>
> obstack_free (&objfile->objfile_obstack, 0);
> objfile->sections = NULL;
> objfile->compunit_symtabs = NULL;
> @@ -2628,6 +2631,20 @@ reread_symbols (void)
> clear_complaints (&symfile_complaints, 1, 1);
>
> objfile->flags &= ~OBJF_PSYMTABS_READ;
> +
> + /* We are about to read new symbols and potentially also DWARF
> + information. Some targets may want to pass addresses read
> from
> + DWARF DIE's through an adjustment function before saving
> them, like
> + MIPS, which may call into "find_pc_section". When called,
> that
> + function will make use of per-objfile program space data.
> +
> + Since we discarded our section information above, we have
> dangling
> + pointers in the per-objfile program space data structure.
> Force
> + GDB to update the section mapping information by letting it
> know
> + the objfile has changed, making the dangling pointers point
> to
> + correct data again. */
> + objfiles_changed ();
> +
> read_symbols (objfile, 0);
>
> if (!objfile_has_symbols (objfile))
>
> @@ -2660,9 +2677,6 @@ reread_symbols (void)
>
> if (!new_objfiles.empty ())
> {
> - /* Notify objfiles that we've modified objfile sections. */
> - objfiles_changed ();
> -
> clear_symtab_users (0);
>
> /* clear_objfile_data for each objfile was called before freeing
> it and
> diff --git a/gdb/testsuite/gdb.base/pr21337.c
> b/gdb/testsuite/gdb.base/pr21337.c
> new file mode 100644
> index 0000000..f8b643a
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/pr21337.c
> @@ -0,0 +1,4 @@
> +int main()
Nit: to match the coding style of GDB:
int
main ()
> +{
> + return 0;
> +}
> diff --git a/gdb/testsuite/gdb.base/pr21337.exp
> b/gdb/testsuite/gdb.base/pr21337.exp
> new file mode 100644
> index 0000000..d7718b4
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/pr21337.exp
Even though there are a few instances of this, we no longer name the
test cases using the PR number. Instead, let's try to find a relevant
name.
Also, you seem to have based your test case on an old file that does not
quite meet today's standards (especially the initial setup/build part).
For an example of test that follows today's practices, look at
gdb.base/step-over-exit.exp, for example.
> @@ -0,0 +1,57 @@
> +# Copyright 1998-2017 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see
> <http://www.gnu.org/licenses/>.
> +
> +set prototypes 1
What does this do?
> +
> +# build the test case
> +
> +set testfile "pr21337"
> +set srcfile ${testfile}.c
> +# Cygwin needs $EXEEXT.
> +set binfile [standard_output_file ${testfile}$EXEEXT]
> +# set binfile ${testfile}
This should be replaced with a call to standard_testfile.
> +
> +set gdbfile [standard_output_file ${testfile}.gdb]
> +
> +if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}"
> executable {debug nowarnings}] != "" } {
No need for "nowarnings".
> + untested "failed to compile first testcase"
> + return -1
> +}
> +
> +# Using the source command to read commands from a file is important,
> +# otherwise section data is freed and reallocated using the same
> +# memory locations and the bug is not exposed.
I don't really know what's different when sourcing a file than typing
commands. But if your experience is that sourcing reproduces the crash
reliably while sending commands does not, I'm fine with that.
> +set ifd [open "$srcdir/$subdir/${testfile}.gdb" r]
> +set ofd [open $gdbfile w]
> +while {[gets $ifd line] >= 0} {
> + regsub $testfile $line $binfile tmp
> + puts $ofd $tmp
> +}
> +close $ifd
> +close $ofd
Would it be simpler to have a procedure to generate the .gdb file with
the right filename from the start? Something like:
proc generate_cmd_file { } {
set ofd [open $gdbfile w]
puts $ofd "file ${binfile}"
puts $ofd "shell sleep 1; touch ${binfile}"
...
}
> +
> +gdb_start
What is your intent in calling gdb_start? I think what you want is just
to start GDB itself, so that it can source the command file below. If
so, you should call clean_restart:
clear_restart ${binfile}
Among other things, this handles the extended-remote target (calling
"set remote exec-file"), which this test case should be able to support.
As in gdb.base/step-over-exit.exp, you can call prepare_for_testing
which does the build + clean_restart for you.
> +
> +if [is_remote target] {
Since your test relies on being able to "run" a program, the right check
would be [use_gdb_stub]:
if [use_gdb_stub] {
> + unsupported $test
> +} else {
> + gdb_test "source $gdbfile" ".*source-command-completed.*" "source
> $testfile.gdb"
> + gdb_test "source $gdbfile" ".*source-command-completed.*" "source
> $testfile.gdb"
Why is it needed to source the file twice?
> +}
> +
> +# End of tests.
> +
> +return 0
This comment and return statement are not necessary.
> diff --git a/gdb/testsuite/gdb.base/pr21337.gdb
> b/gdb/testsuite/gdb.base/pr21337.gdb
> new file mode 100644
> index 0000000..42fac26
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/pr21337.gdb
> @@ -0,0 +1,13 @@
> +file pr21337
> +shell sleep 1; touch pr21337
> +run
> +file
> +file pr21337
> +shell sleep 1; touch pr21337
> +run
> +file
> +file pr21337
> +shell sleep 1; touch pr21337
> +run
> +file
> +p "source-command-completed"
Thanks for adding a test case!
Simon
next prev parent reply other threads:[~2017-05-12 3:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 23:04 [PATCH] [mips] Fix PR 21337 v1: " Doug Gilmore
2017-04-10 16:01 ` Doug Gilmore
2017-04-12 18:52 ` Luis Machado
2017-04-12 21:42 ` Doug Gilmore
2017-04-13 18:56 ` [PATCH] Fix PR 21337 v2: " Doug Gilmore
2017-04-14 15:33 ` Luis Machado
2017-04-22 2:15 ` Simon Marchi
2017-04-25 18:16 ` Doug Gilmore
2017-04-27 19:46 ` Simon Marchi
2017-04-28 23:44 ` Doug Gilmore
2017-04-29 1:13 ` Luis Machado
2017-04-29 1:42 ` Simon Marchi
2017-04-29 17:12 ` Doug Gilmore
2017-04-29 23:26 ` Simon Marchi
2017-04-30 5:14 ` Doug Gilmore
2017-05-10 23:26 ` Doug Gilmore
2017-05-12 3:29 ` Simon Marchi [this message]
2017-05-12 19:24 ` Doug Gilmore
2017-05-16 23:11 ` [PATCH] Fix PR 21337 (v3): " Doug Gilmore
2017-06-06 16:08 ` [PING][PATCH] " Doug Gilmore
2017-06-23 18:20 ` [PING^2][PATCH] " Doug Gilmore
2017-06-25 11:25 ` [PATCH] " Simon Marchi
2017-06-27 17:29 ` [PATCH] Fix PR 21337 (v4): " Doug Gilmore
2017-06-27 21:35 ` Doug Gilmore
2017-06-28 2:01 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09492e58ce0daf1efee14636bc5312cc@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=Doug.Gilmore@imgtec.com \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox