This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH 1/3] Added command remove-symbol-file.
- From: "Blanc, Nicolas" <nicolas dot blanc 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: Tue, 28 May 2013 11:25:14 +0000
- Subject: RE: [PATCH 1/3] Added command remove-symbol-file.
- References: <1366098721-18302-1-git-send-email-nicolas dot blanc at intel dot com> <1366098721-18302-2-git-send-email-nicolas dot blanc at intel dot com> <517ABA6A dot 5070400 at redhat dot com> <388084C8C1E6A64FA36AD1D656E4856619DF0224 at IRSMSX102 dot ger dot corp dot intel dot com> <517EC93F dot 2020409 at redhat dot com> <388084C8C1E6A64FA36AD1D656E4856619DF0550 at IRSMSX102 dot ger dot corp dot intel dot com> <518A91D0 dot 5010205 at redhat dot com>
Hi Pedro,
I just returned from vacations. Sorry for the delay.
Just comparing addr_low for re-using object-files when loading a new SO might indeed be incorrect.
But one may consider the current behavior of GDB as a feature, e.g.: the user knows something additional
and want to overwrite the default mapping. So I would not change GDB.
To me, the remove-symbol-file command should remove the file even if it is currently
shared because the user might have a good reason for doing this.
Regards,
Nicolas
> So what is the desirable behavior for when the user does add-symbol-file and then the program loads the same file, and then the user removes the file she added. GDB drops symbols until the next DSO > event or next "sharedlibrary"
> command invocation? The fact that GDB reuses the same file when the addr_low happens to match looks quite brittle (it doesn't check the section offsets (passed to add-symbol-file) are the same, for > instance). I wonder whether this sharing is supposed to be a valid use case, and whether it wouldn't be better and simpler to disable it, that is,
>
> /* Have we already loaded this shared object? */
> ALL_OBJFILES (so->objfile)
> {
> if (filename_cmp (so->objfile->name, so->so_name) == 0
> && so->objfile->addr_low == so->addr_low
>- && so->objfile->addr_low == so->addr_low)
>+ && !(so->objfile->flags & OBJF_USERLOADED))
> break;
> }
>
>...
>
>- /* Unless the user loaded it explicitly, free SO's objfile. */
>- if (gdb->objfile && ! (gdb->objfile->flags & OBJF_USERLOADED)
>- && !solib_used (gdb))
>- free_objfile (gdb->objfile);
>
>
>In a way, treat manually added objfiles list and the dynamic SO list separate lists.
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