This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] don't share per-BFD data if relocations are needed
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 27 Aug 2013 19:02:33 +0100
- Subject: Re: [PATCH 1/2] don't share per-BFD data if relocations are needed
- Authentication-results: sourceware.org; auth=none
- References: <1376512619-3211-1-git-send-email-tromey at redhat dot com> <1376512619-3211-2-git-send-email-tromey at redhat dot com>
On 08/14/2013 09:36 PM, Tom Tromey wrote:
> Right now we always share per-BFD data across objfiles, if there is a
> BFD. This works fine. However, we're going to start sharing more
> data, and sometimes this data will come directly from sections of the
> BFD. If such a section has SEC_RELOC set, then the data coming from
> that section will not be truly sharable -- the section will be
> program-space-dependent, and re-read by gdb for each objfile.
>
> This patch disallows per-BFD sharing in this case. This is a bit
> "heavy" in that we could in theory examine each bit of shared data for
> suitability. However, that is more complicated, and SEC_RELOC is rare
> enough that I think we needn't bother.
Yeah, some targets use relocatable objects as main binary format,
but I agree we don't need to bother.
> @@ -139,7 +139,10 @@ get_objfile_bfd_data (struct objfile *objfile, struct bfd *abfd)
>
> if (storage == NULL)
> {
> - if (abfd != NULL)
> + /* If the object requires gdb to do relocations, we simply fall
> + back to not sharing data across users. These cases are rare
> + enough that this seems reasonable. */
> + if (abfd != NULL && !gdb_bfd_requires_relocations (abfd))
> {
> storage = bfd_zalloc (abfd, sizeof (struct objfile_per_bfd_storage));
> set_bfd_data (abfd, objfiles_bfd_data, storage);
>
Shouldn't we still set storage->gdbarch to the bfd's gdbarch?
Otherwise looks fine to me.
--
Pedro Alves