This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] don't share per-BFD data if relocations are needed


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]