From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
To: Aaron Merey <amerey@redhat.com>
Cc: aburgess@redhat.com, gdb-patches@sourceware.org
Subject: Re: [PATCH 3/4 v4] gdb/debuginfod: Support on-demand debuginfo downloading
Date: Tue, 26 Dec 2023 15:35:26 -0300 [thread overview]
Message-ID: <87o7ecerrl.fsf@linaro.org> (raw)
In-Reply-To: <20231028002008.1105723-4-amerey@redhat.com>
Aaron Merey <amerey@redhat.com> writes:
> +void
> +dwarf2_gdb_index::expand_matching_symbols
> + (struct objfile *objfile,
> + const lookup_name_info &lookup_name,
> + domain_enum domain,
> + int global,
> + symbol_compare_ftype *ordered_compare)
> +{
> + try
> + {
> + do_expand_matching_symbols (objfile, lookup_name, domain,
> + global, ordered_compare);
> + }
> + catch (const gdb_exception &e)
> + {
> + if ((objfile->flags & OBJF_DOWNLOAD_DEFERRED) == 0)
> + exception_print (gdb_stderr, e);
> + else
> + read_full_dwarf_from_debuginfod (objfile, this);
> + return;
"return" is redundant here. I suggest removing it.
> + }
> +}
> +void
> +read_full_dwarf_from_debuginfod (struct objfile *objfile,
> + dwarf2_base_index_functions *fncs)
> +{
> + gdb_assert (objfile->flags & OBJF_DOWNLOAD_DEFERRED);
> +
> + const struct bfd_build_id *build_id = build_id_bfd_get (objfile->obfd.get ());
> + const char *filename;
> + gdb_bfd_ref_ptr debug_bfd;
> + gdb::unique_xmalloc_ptr<char> symfile_path;
> + scoped_fd fd;
The "goto unset"s in this function make me wonder whether it is
exception-safe. If SCOPE_EXIT is used at this point like so:
SCOPE_EXIT { objfile->remove_deferred_status (); };
can it correctly replace the gotos?
> +
> + if (build_id == nullptr)
> + goto unset;
> +
> + filename = bfd_get_filename (objfile->obfd.get ());
> + fd = debuginfod_debuginfo_query (build_id->data, build_id->size,
> + filename, &symfile_path);
> + if (fd.get () < 0)
> + goto unset;
> +
> + /* Separate debuginfo successfully retrieved from server. */
> + debug_bfd = symfile_bfd_open (symfile_path.get ());
> + if (debug_bfd == nullptr
> + || !build_id_verify (debug_bfd.get (), build_id->size, build_id->data))
> + {
> + warning (_("File \"%s\" from debuginfod cannot be opened as bfd"),
> + filename);
> + goto unset;
> + }
> +
> + /* Clear frame data so it can be recalculated using DWARF. */
> + dwarf2_clear_frame_data (objfile);
> +
> + /* This may also trigger a dwz download. */
> + symbol_file_add_separate (debug_bfd, symfile_path.get (),
> + current_inferior ()->symfile_flags, objfile);
> +
> +unset:
> + objfile->remove_deferred_status ();
> +}
> +
> +/* See public.h. */
> +
> +bool
> +dwarf2_has_separate_index (struct objfile *objfile)
> +{
> + if (objfile->flags & OBJF_DOWNLOAD_DEFERRED)
> + return true;
> + if (objfile->flags & OBJF_MAINLINE)
> + return false;
> + if (!IS_DIR_SEPARATOR (*objfile_filename (objfile)))
> + return false;
> +
> + gdb::unique_xmalloc_ptr<char> index_path;
I hope this isn't too pedantic, but the index_path declaration can be
moved right above the call to debuginfod_section_query.
> + const bfd_build_id *build_id = build_id_bfd_get (objfile->obfd.get ());
> +
> + if (build_id == nullptr)
> + return false;
> +
> + scoped_fd fd = debuginfod_section_query (build_id->data,
> + build_id->size,
> + bfd_get_filename
> + (objfile->obfd.get ()),
> + ".gdb_index",
> + &index_path);
<snip>
> diff --git a/gdb/objfiles.h b/gdb/objfiles.h
> index c20b63ceadf..ea9bd2157dc 100644
> --- a/gdb/objfiles.h
> +++ b/gdb/objfiles.h
> @@ -612,6 +612,26 @@ struct objfile
> /* See quick_symbol_functions. */
> void require_partial_symbols (bool verbose);
>
> + /* Indicate that the aquisition of this objfile's separate debug objfile
> + is no longer deferred. Used when the debug objfile has been aquired
*acquired
> + or could not be found. */
> + void remove_deferred_status ()
<snip>
> +void
> +libsection1_test ()
> +{
> + pthread_t thr;
> +
> + printf ("In libsection1\n");
> + libsection2_test ();
> +
> + pthread_create (&thr, NULL, libsection2_thread_test, NULL);
> +
> + /* Give the new thread a chance to actually enter libsection2_thread_test. */
> + sleep (3);
If the testcase is run in a slow simulator, it can take more than 3
seconds. Or in a heavily loaded machine. Can the test use
pthread_cond_wait/pthread_cond_signal instead?
> + printf ("Cancelling thread\n");
> +
> + pthread_cancel (thr);
> +}
<snip>
> +# Restart GDB and clear the debuginfod client cache. Then load BINFILE into
> +# GDB and start running it. Match output with pattern RES and use TESTNAME
> +# as the test name.
> +proc_with_prefix clean_restart_with_prompt { binfile res testname } {
The res argument isn't used by the function.
> + global cache
> +
> + # Delete client cache so debuginfo downloads again.
> + file delete -force $cache
> + clean_restart
> +
> + gdb_test "set debuginfod enabled on" "" "clean_restart enable $testname"
> + gdb_load $binfile
> +
> + if {![runto_main]} {
> + return
Isn't this return redundant? Suggest ending the procedure with just
"[runto_main]".
> + }
> +}
--
Thiago
next prev parent reply other threads:[~2023-12-26 18:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-28 0:20 [PATCH 0/4] On-demand " Aaron Merey
2023-10-28 0:20 ` [PATCH 1/4 v7] gdb: Buffer output streams during events that might download debuginfo Aaron Merey
2023-11-12 20:20 ` Aaron Merey
2023-11-20 18:38 ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:29 ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:00 ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:57 ` [PING*5][PATCH " Aaron Merey
2023-12-26 16:28 ` [PATCH " Thiago Jung Bauermann
2024-01-17 17:49 ` Aaron Merey
2024-01-17 18:05 ` Andrew Burgess
2023-10-28 0:20 ` [PATCH 2/4 v2] gdb/progspace: Add reverse safe iterator and template for unwrapping iterator Aaron Merey
2023-11-12 20:20 ` Aaron Merey
2023-11-20 18:39 ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:30 ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:01 ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:57 ` [PING*5][PATCH " Aaron Merey
2023-12-26 17:09 ` [PATCH " Thiago Jung Bauermann
2023-10-28 0:20 ` [PATCH 3/4 v4] gdb/debuginfod: Support on-demand debuginfo downloading Aaron Merey
2023-11-12 20:20 ` Aaron Merey
2023-11-20 18:39 ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:30 ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:01 ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:57 ` [PING*5][PATCH " Aaron Merey
2023-12-26 18:35 ` Thiago Jung Bauermann [this message]
2023-10-28 0:20 ` [PATCH 4/4 v5] gdb/debuginfod: Add .debug_line downloading Aaron Merey
2023-11-12 20:21 ` Aaron Merey
2023-11-20 18:40 ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:30 ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:08 ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:58 ` [PING*5][PATCH " Aaron Merey
2023-12-27 0:30 ` [PATCH " Thiago Jung Bauermann
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=87o7ecerrl.fsf@linaro.org \
--to=thiago.bauermann@linaro.org \
--cc=aburgess@redhat.com \
--cc=amerey@redhat.com \
--cc=gdb-patches@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).