This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: 32-bit gcore on amd64
- From: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>
- To: cagney at gnu dot org
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 20 Feb 2004 00:47:28 +0100 (CET)
- Subject: Re: 32-bit gcore on amd64
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