symtab/1853: GDB does not reinitialize the architecture when reloading a binary

[drow at false dot org]

>Number:         1853
>Category:       symtab
>Synopsis:       GDB does not reinitialize the architecture when reloading a binary
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 26 17:18:00 UTC 2005
>Closed-Date:
>Last-Modified:
>Originator:     drow@false.org
>Release:        CVS 2005-01-26
>Organization:
>Environment:

>Description:
When GDB rereads a changed symbol file for the main application, it doesn't try to reinitialize gdbarch.  If the new binary has a different architecture than the old one, this can cause very strange bugs.  For instance, if the old and new binaries had different endianness - accidentally start GDB on a big-endian binary, realize you used the wrong one, copy in the new little-endian binary, target remote triggers a reread of symbols because the binary has changed, and GDB has the wrong endianness.

I didn't test that specific example; the example I'm using involved local patches in which the register cache layout is determined by the BFD mach (ugh).  When I replace an incorrectly tagged binary by a correctly tagged one, and reconnect to the remote stub, GDB still uses the wrong g packet layout.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: