This is the mail archive of the gdb-patches@sources.redhat.com 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/RFA] Don't gdbarch_init for core files


> How about this?
> 
> 	* corelow.c (core_open): If the core's arch is known and
> 	different from the current, reinitialize gdbarch based on
> 	the core file.
> 

Hmm, thing is:

> -  set_gdbarch_from_file (core_bfd);
> +  /* If the core's arch is known and different from the current,
> +     reinitialize gdbarch based on the core file.  */
> +
> +  current_arch_info = gdbarch_bfd_arch_info (current_gdbarch);
> +  if (core_bfd->arch_info->arch != bfd_arch_unknown
> +      && core_bfd->arch_info->arch != current_arch_info->arch)
> +    set_gdbarch_from_file (core_bfd);

is [almost] no different to deleting the call - GDB isn't yet built with 
multiple architectures so the two architectures will always be identical.

Looking at the date/author of the original patch [and making a wild 
guess], I think the original change was related to debugging 32 bit core 
files on a SPARC64 system.  Michael?

For the moment, bfd's compatible() might be the best test (does it give 
the effect you're looking for?).  The other approach is to enhance the 
relevant architecture vectors so that they don't change the architecture 
for cases like this.  I think, eventually, the ABI/OS stuff will help 
solve this problem.  Anway, what ever the change, it will need plenty 
comments :-)

enjoy,
Andrew


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