32-bit gcore on amd64

[Andrew Cagney]

>>>This function totally assumes that it's creating a 64-bit note section. 
>>>How does BFD figure out that it should instead use 32-bit note code?
> 
> 
> It doesn't, as far as I can see.

Ah, "good", at least I wasn't missing anything.

>>>As a somewhat amazing PS: bigcore.exp does pass 32-bit mode on 
>>>AMD-64 ->> the 32-bit read path is ok.
> 
> 
> That's because there are tons of special-cased code pieces in
> the *read* path to handle this; check for HAVE_PRPSINFO32_T
> and HAVE_PRSTATUS32_T in bfd/elf.c.  (This relies on sys/procfs.h
> to provide both 32-bit and 64-bit versions -- reading cores
> didn't work initially on s390x because those were missing.)
> 
> Such special cases are completely absent from the write path,
> however.
> 
> (The other question is whether these 32-on-64 special cases are
> really the right way to solve the problem -- a generic solution
> should preferably solve the any-on-any cross-gdb core dump 
> access problem ...)

That's why I'm thinking that:

> #4  0x00000000004583f8 in linux_make_note_section (obfd=0x87fc90,
>     note_size=0x7fbfffed8c) at /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:302
> 
> Here, I'm thinking that if this is to be portable, this would have to be an architecture method (also parameterized with the target).

belongs in the architecture vector.

Andrew