Re: 32-bit gcore on amd64

[Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>]

Andrew Cagney wrote:

>This is more questions than answers. I'm trying to figure out how GDB 
>should generate 32-bit core files on amd64 (i.e., get gmake check 
>'RUNTESTFLAGS=--target_board=unix/-m32 gcore.exp' to pass). 
>The problem is, everything I look at feels wrong.

Yup, same problem on s390x.  In fact, the gcore tests are the only
failing tests when running the s390-on-s390x bi-arch test suite
(in addition to those that fail on native s390, of course).

[snip elfcore_write_prstatus]
>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.

>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 ...)
 
Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de