This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 4 Jun 2014 12:35:44 +0000
- Subject: RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
- Authentication-results: sourceware.org; auth=none
- References: <1400655682-4014-1-git-send-email-markus dot t dot metzger at intel dot com> <1400655682-4014-3-git-send-email-markus dot t dot metzger at intel dot com> <5387663A dot 5040704 at redhat dot com> <53876874 dot 3080503 at redhat dot com> <A78C989F6D9628469189715575E55B230C182CFC at IRSMSX104 dot ger dot corp dot intel dot com>
Hi Pedro,
I sent this as a patch:
https://sourceware.org/ml/gdb-patches/2014-06/msg00148.html
There's also another patch series open that fixes an assertion when
generating a core file while replaying:
https://sourceware.org/ml/gdb-patches/2014-05/msg00537.html
https://sourceware.org/ml/gdb-patches/2014-05/msg00539.html
https://sourceware.org/ml/gdb-patches/2014-05/msg00538.html
regards,
markus.
> -----Original Message-----
> From: Metzger, Markus T
> Sent: Monday, June 2, 2014 2:41 PM
> To: Pedro Alves
> Cc: gdb-patches@sourceware.org
> Subject: RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
>
> > -----Original Message-----
> > From: Pedro Alves [mailto:palves@redhat.com]
> > Sent: Thursday, May 29, 2014 7:04 PM
>
>
> > Hmm, wait, nothing is removing the vdso symbols target sections, like ever,
> > not even when the process dies, isn't it? I guess that's it.
>
> Yes, that seems to be it.
>
> Target sections are typically owned by an so_list object and are removed
> when the so_list object is removed.
>
> Symfile target sections are owned by an objfile object and are removed
> in a free_objfile observer in symfile.c. That observer only removes target
> sections for OBJF_USERLOADED objfiles, though.
>
> The vdso target sections are owned by the vdso BFD and are never removed.
>
> When I change symfile_add_from_memory to create target sections like
> this:
>
> add_target_sections_of_objfile (objf);
>
> and further drop the restriction to only remove OBJF_USERLOADED objfiles
> in
> symfile_free_objfile, the test passes.
>
> diff --git a/gdb/symfile-mem.c b/gdb/symfile-mem.c
> index b29421e..ef48f7d 100644
> --- a/gdb/symfile-mem.c
> +++ b/gdb/symfile-mem.c
> @@ -92,7 +92,6 @@ symbol_file_add_from_memory (struct bfd *templ,
> CORE_ADDR addr,
> struct section_addr_info *sai;
> unsigned int i;
> struct cleanup *cleanup;
> - struct target_section *sections, *sections_end, *tsec;
>
> if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
> error (_("add-symbol-file-from-memory not supported for this target"));
> @@ -132,22 +131,7 @@ symbol_file_add_from_memory (struct bfd *templ,
> CORE_ADDR addr,
> from_tty ? SYMFILE_VERBOSE : 0,
> sai, OBJF_SHARED, NULL);
>
> - sections = NULL;
> - sections_end = NULL;
> -
> - if (build_section_table (nbfd, §ions, §ions_end) == 0)
> - {
> - make_cleanup (xfree, sections);
> -
> - /* Adjust the target section addresses by the load address. */
> - for (tsec = sections; tsec != sections_end; ++tsec)
> - {
> - tsec->addr += loadbase;
> - tsec->endaddr += loadbase;
> - }
> -
> - add_target_sections (&nbfd, sections, sections_end);
> - }
> + add_target_sections_of_objfile (objf);
>
> /* This might change our ideas about frames already looked at. */
> reinit_frame_cache ();
> diff --git a/gdb/symfile.c b/gdb/symfile.c
> index 64a83c6..caa0722 100644
> --- a/gdb/symfile.c
> +++ b/gdb/symfile.c
> @@ -3893,7 +3893,7 @@ static void
> symfile_free_objfile (struct objfile *objfile)
> {
> /* Remove the target sections of user-added objfiles. */
> - if (objfile != 0 && objfile->flags & OBJF_USERLOADED)
> + if (objfile != NULL)
> remove_target_sections ((void *) objfile);
> }
>
> Alternatively, I could add another OBJF_ flag and another free_objfile
> observer
> to also remove the symfile-from-memory target sections.
>
> Regards,
> Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052