This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 ...)
#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).
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |