Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: thorpej@wasabisystems.com, Michael Snyder <msnyder@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFA] Don't gdbarch_init for core files
Date: Sat, 11 May 2002 19:48:00 -0000	[thread overview]
Message-ID: <3CDDD7ED.9080302@cygnus.com> (raw)
In-Reply-To: <20020509212134.W3435@dr-evil.shagadelic.org>

> 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


  reply	other threads:[~2002-05-12  2:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-09 18:58 Jason R Thorpe
2002-05-09 20:04 ` Andrew Cagney
2002-05-09 21:21   ` Jason R Thorpe
2002-05-11 19:48     ` Andrew Cagney [this message]
2002-05-11 20:30       ` Jason R Thorpe
2002-05-11 20:46         ` Daniel Jacobowitz
2002-05-16 16:24           ` Michael Snyder
2002-05-16 16:24       ` Michael Snyder
2002-05-16 17:33         ` Andrew Cagney
2002-05-17  6:58 m.m.kettenis
2002-05-17 10:47 ` Jason R Thorpe
2002-05-17 10:59   ` Michael Snyder
2002-05-17 16:06     ` Mark Kettenis
2002-05-17 10:54 ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CDDD7ED.9080302@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    --cc=thorpej@wasabisystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox