AIX 32-bit core loading, high section addresses.

I noticed GDB was failing to enable threading support for 32-bit AIX
cores.  I traced it to failure to read variables from libpthreads.a.
The issue is that data for that library is loaded at a high address,
and bfd is sign extending the section addresses:

 (gdb) info files
 Symbols from "/home/palves/crash".
 Local core dump file:
	 `/home/palves/core', file type aixcoff-rs6000.
	 0x2ff22000 - 0x2ff23000 is .stack
	 0x20000000 - 0x200316e0 is .data
	 0x20000e90 - 0x200016c0 is .data
	 0xfffffffff0254000 - 0xfffffffff0297920 is .data
	 0xfffffffff07b46a8 - 0xfffffffff07b47c8 is .data
	 0xfffffffff0298000 - 0xfffffffff029bfcc is .data
	 0xfffffffff06dafe0 - 0xfffffffff07b3838 is .data
 Local exec file:
	 `/home/palves/crash', file type aixcoff-rs6000.
	 Entry point: 0x20001394
	 0x10000150 - 0x10000e90 is .text
	 0x20000e90 - 0x2000149c is .data
	 0x2000149c - 0x200016c0 is .bss
	 0xd053b124 - 0xd053e15f is .text in /usr/lib/libpthreads.a(shr_comm.o)
	 0xf0254000 - 0xf0297920 is .data in /usr/lib/libpthreads.a(shr_comm.o)
	 0xf0254450 - 0xf0297920 is .bss in /usr/lib/libpthreads.a(shr_comm.o)
	 0xd053a280 - 0xd053aabe is .text in /usr/lib/libcrypt.a(shr.o)
	 0xf07b46a8 - 0xf07b47c8 is .data in /usr/lib/libcrypt.a(shr.o)
	 0xf07b47c8 - 0xf07b47c8 is .bss in /usr/lib/libcrypt.a(shr.o)
	 0xd04fb180 - 0xd053917e is .text in /usr/lib/libpthreads.a(shr_xpg5.o)
	 0xf0298000 - 0xf029bfcc is .data in /usr/lib/libpthreads.a(shr_xpg5.o)
	 0xf029bf64 - 0xf029bfcc is .bss in /usr/lib/libpthreads.a(shr_xpg5.o)
	 0xd0100900 - 0xd04fa39c is .text in /usr/lib/libc.a(shr.o)
	 0xf06dafe0 - 0xf07b3838 is .data in /usr/lib/libc.a(shr.o)
	 0xf0751e94 - 0xf07b3838 is .bss in /usr/lib/libc.a(shr.o)

Notice:
	...
	0xfffffffff0298000 - 0xfffffffff029bfcc is .data
	...

Those are the bfd section start/end addresses.  It't not visible here:

         ...
	 0xf0298000 - 0xf029bfcc is .data in /usr/lib/libpthreads.a(shr_xpg5.o)
         ...

... just because GDB trims that number to 32-bit when printing.

GDB then fails to find the memory for libpthreads.a variables in the
core, and falls back to reading it directly from the executable (which
yields the values as originally initialized in the code).

E.g.:

 (gdb) p &__n_pthreads
 $2 = (<data variable, no debug info> *) 0xf074fda8 <__n_pthreads>
 (gdb) p __n_pthreads
 $1 = -1

That should have returned 2 instead of -1.

bfd/
2014-03-07  Pedro Alves  <palves@redhat.com>

	* rs6000-core.c (rs6000coff_core_p): Cast pointers to bfd_vma
	through ptr_to_uint instead of through long.
AIX threaded cores.

AIX threaded cores came up in the target-async series.  I tried things
out on gcc111, but stumbled on a couple things.  First, a BFD patch
was necessary:
<https://sourceware.org/ml/binutils/2014-03/msg00052.html>

Then, I found out that even after that, we have more breakage:

 [New Thread 1]
 [New Thread 258]
 Error in re-setting breakpoint -1: aix-thread: ptrace (52, 25231783) returned -1 (errno = 3 The process does not exist.)
 Error in re-setting breakpoint -1: aix-thread: ptrace (52, 25231783) returned -1 (errno = 3 The process does not exist.)
 Core was generated by `crash'.
 Program terminated with signal SIGABRT, Aborted.
 #0  0xd05187c0 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
 (gdb) info threads
   Id   Target Id         Frame
   3    Thread 258 (tid 25231783, running) aix-thread: ptrace (52, 25231783) returned -1 (errno = 3 The process does not exist.)
...

Obviously, we shouldn't be using ptrace when debugging cores...

So I wrote this GDB-side patch below last night, and now get the
number of threads right:

 [New Thread 1]
 [New Thread 258]
 Core was generated by `crash'.
 Program terminated with signal SIGABRT, Aborted.
 #0  0xd05187c0 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
 (gdb) info threads
   Id   Target Id         Frame
   3    Thread 258 (tid 25231783, running) 0xd05187c0 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
   2    Thread 1 (tid 88801287, sleeping) 0xd05187c0 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
 * 1    process 1         0xd05187c0 in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)

... and no ptrace errors.  Good.

But, then all threads show the same registers (and that's wrong,
thread 3 isn't really stopped in pthread_kill).  That's because the
bfd side doesn't know to create .reg/NNN sections for each kernel
thread in the core...  Bad.

$ objdump -h ~/core

/home/palves/core:     file format aixcoff-rs6000

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .stack        00001000  2ff22000  00000000  00000e9c  2**8
                  CONTENTS, ALLOC, LOAD
  1 .reg          00000250  00000000  00000000  000001a0  2**8
                  CONTENTS
  2 .ldinfo       000000fc  00000000  00000000  00000a88  2**8
                  CONTENTS
  3 .data         000316e0  20000000  00000000  00122170  2**8
                  CONTENTS, ALLOC, LOAD
  4 .data         00000830  20000e90  00000000  00123000  2**8
                  CONTENTS, ALLOC, LOAD
  5 .data         00043920  f0254000  00000000  00001f0c  2**8
                  CONTENTS, ALLOC, LOAD
  6 .data         00000120  f07b46a8  00000000  0004582c  2**8
                  CONTENTS, ALLOC, LOAD
  7 .data         00003fcc  f0298000  00000000  0004594c  2**8
                  CONTENTS, ALLOC, LOAD
  8 .data         000d8858  f06dafe0  00000000  00049918  2**8
                  CONTENTS, ALLOC, LOAD

Not sure if threaded cores ever worked on AIX.  There are comments in
the code that might suggest so.  But maybe that was on machines where
all user threads map to one kernel thread.  Dunno.

So to make this fully work, we'd need something like the below on the
GDB side, but we'd also need to fix the bfd side.  I'm clueless on
xcoff core format though, and I don't really plan on learning it
now...  But I thought I'd post this anyway for the archives.
Leftovers.