Avoid short i386 register names on Solaris/x86 [PR25981]

This is the 32-bit companion to

	Remove unused ps_lgetLDT etc. on Solaris/x86 [PR25981]
        https://sourceware.org/pipermail/gdb-patches/2020-May/168713.html

A 32-bit-default gdb fails to compile with the updated <sys/regset.h>.
While it is also affected by the lack of a GS definition, which the
compantion patch above fixes, it also fails to compile i386-sol2-nat.c like
this

/vol/src/gnu/gdb/hg/master/git/gdb/i386-sol2-nat.c:181:3: error: 'EAX' was not declared in this scope
  181 |   EAX, ECX, EDX, EBX,
      |   ^~~

and several more.

While this could be fixed by either including <ucontext.h> here or
provding fallback definitions of the register macros, I chose to do what
the 64-bit-default code in the same file
(amd64_sol2_gregset32_reg_offset[]) does, namely just hardcode the
numeric values instead.  They are part of the ABI and thus guaranteed
not to change.

With this patch, a i386-pc-solaris2.11 configuration on master compiles
again, however, it doesn't work.  However, I could successfully test it
on the gdb-9 branch.

Compiling and testing proved to be messy, unfortunately:

* For one, Solaris <sys/procfs.h> and largefile support used to be
  mutually exclusive (fixed in Solaris 11.4 and Illumos), which was
  exacerbated by the fact that g++ predefines _FILE_OFFSET_BITS=64 since
  GCC 9.1.0.  For now I've worked around this by adding
  -U_FILE_OFFSET_BITS to CXXFLAGS and configuring with
  --disable-largefile.  I hope to clean this up in a future patch.

* gdb still defaults to startup-with-shell on.  However, /bin/bash is a
  64-bit executable which cannot be debugged by a 32-bit gdb.  I hacked
  around that part by pointing $SHELL at a 32-bit bash before running
  make check.

	PR build/25981
	* i386-sol2-nat.c [PR_MODEL_NATIVE != PR_MODEL_LP64] (regmap):
	Hardcode register numbers.

0 files changed, 0 insertions, 0 deletions