Re: [RFC] Core files and the architecture vector

[Andrew Cagney <ac131313@redhat.com>]

> When a 32-bit executable
> running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an
> 64-bit ELF core file.

I think that's a kernel bug.  A 32 bit emulation environment should 
emulate things right down to the binary format of a core dump :-)

However ...

> The problem I'm having, is that we have no clean seperation between
> initalizing and activating an architecture vector; it's all done from
> gdbarch.c:gdbarch_update_p().  Looking at the function, it seems as if
> it's not quite so easy to seperate the two because of the
> per-architecture swapped data.  I've hacked around this by
> unconditionally setting the architecture from CORE_BFD, fetching the
> core architecture vector from CURRENT_GDBARCH, and reset the
> architecture from EXEC_BFD if we have one; refer to the attached code
> to see what I mean.
> 
> Is this kosher?  Do folks agree with this approach?

Is this kosher?  No.  Is there a better way?  No.

GDBARCH methods that give the appearance of returning an architecture 
(without affecting global state) vis:

	struct gdbarch *gdbarch_from_file ();

are going to be needed (however, right now they would only allow us to 
fool ourselves into thinking we're safe :-).  A method like:

	struct gdbarch *deprecated_select_gdbarch_hack (struct gdbarch *);

method might also be useful?

Andrew

PS: This is only going to get worse - target <>- thread <>- frame will 
have an equally messy transition.

PPS: Suggest more "rude" comments about how dangerous this is.