32-bit gcore on amd64
Ulrich Weigand
weigand@i1.informatik.uni-erlangen.de
Thu Feb 19 23:47:00 GMT 2004
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
More information about the Gdb
mailing list