From mboxrd@z Thu Jan 1 00:00:00 1970 From: Orjan Friberg To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] Swap out current when creating a new architecture Date: Tue, 16 Oct 2001 01:59:00 -0000 Message-id: <3BCBF6E3.73B404@axis.com> References: <3BB16441.30805@cygnus.com> <3BB771A1.4070201@cygnus.com> <3BB854B3.208DC17A@axis.com> <3BCA28A3.6010607@cygnus.com> <3BCB902A.8090003@cygnus.com> X-SW-Source: 2001-10/msg00233.html Andrew Cagney wrote: > > Really nice bug! > > The proposed change unfortunatly isn't right for reasons similar to the > original current_gdbarch problem. The exec file might belong to a > completely different architecture. Consider a sequence like: > > (gdb) file hello.d10v > (gdb) info architecture > The current architecture is d10v > (gdb) set cris-mode CRIS_MODE_USER Hm, I had a feeling I was just moving the problem elsewhere, though I didn't think of the case of having gdb configured for two architectures. But with multi-arch I guess this is not just a remote possibility. > For MIPS, the problem has so far been avoided by coding functions as: > > if (set by user) > return user value; > else > return value from architecture; > >From looking at the MIPS target just now I thought it would suffer from the same problem when it comes to guessing the ABI (since info.abfd is used if present). But then I saw that the functions tied to the MIPS specific user-commands don't call gdbarch_update, they change current_gdbarch directly. I'm going to try something similar. Thanks, Orjan -- Orjan Friberg E-mail: orjan.friberg@axis.com Axis Communications AB Phone: +46 46 272 17 68