present on rhel-7 too

$ file bz1037279/coredump-ppc
bz1037279/coredump-ppc: ELF 32-bit MSB core file, PowerPC or cisco 4500, version 1 (SYSV), SVR4-style


+++ This bug was initially created as a clone of Bug #1037279 +++

Description of problem:

On rhel5 we see the following output.

[root@rhel5 ~]# file core_crashme.tsk_linux_ppc64
core_crashme.tsk_linux_ppc64: ELF 32-bit MSB core file, PowerPC or cisco 4500, version 1 (SYSV), SVR4-style, from 'crashme.tsk'

While on rhel6 we see.

[root@rhel6 ~]# file core_crashme.tsk_linux_ppc64 
core_crashme.tsk_linux_ppc64: ELF 32-bit MSB core file, PowerPC or cisco 4500, version 1 (SYSV), SVR4-style

Version-Release number of selected component (if applicable):
file-5.04-15.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Find a ppc64 machine
2. create a 32 bit executable and get a core file from it
3. Run file on the core

Actual results:
core_crashme.tsk_linux_ppc64: ELF 32-bit MSB core file, PowerPC or cisco 4500, version 1 (SYSV), SVR4-style

Expected results:
core_crashme.tsk_linux_ppc64: ELF 32-bit MSB core file, PowerPC or cisco 4500, version 1 (SYSV), SVR4-style, from 'crashme.tsk'

Additional info:

eu-readelf finds the right information in the pspargs structure.

# eu-readelf -n crashme.tsk_linux_ppc64|grep fname 
     fname: crashme.tsk, psargs: ./crashme.tsk 

After much staring at this I worked out this was due to a change in the prpsoffsets32 array, specifically the removal (why?) of offset 32 which is required for ppc32 cores.

I did a git bisect and found the commit.

commit 44e1422ae38bcacf91d6ddb0893adc42bc0a5fed
Author: Christos Zoulas <christos@zoulas.com>
Date:   Thu Jun 8 20:53:31 2006 +0000

    linux changes from suse

diff --git a/src/readelf.c b/src/readelf.c
index e7a0d72..e3c1a3a 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -37,7 +37,7 @@
 #include "readelf.h"
 
 #ifndef lint
-FILE_RCSID("@(#)$Id: readelf.c,v 1.55 2006/05/03 15:50:24 christos Exp $")
+FILE_RCSID("@(#)$Id: readelf.c,v 1.56 2006/06/08 20:53:31 christos Exp $")
 #endif
 
 #ifdef ELFCORE
@@ -191,15 +191,16 @@ getu64(int swap, uint64_t value)
 #ifdef ELFCORE
 size_t prpsoffsets32[] = {
        8,              /* FreeBSD */
-       28,             /* Linux 2.0.36 */
-       32,             /* Linux (I forget which kernel version) */
+       28,             /* Linux 2.0.36 (short name) */
+       44,             /* Linux (path name) */
        84,             /* SunOS 5.x */
 };
 
 size_t prpsoffsets64[] = {
        16,             /* FreeBSD, 64-bit */
-       40,             /* Linux (tested on core from 2.4.x) */
-       120,            /* SunOS 5.x, 64-bit */
+       40,             /* Linux (tested on core from 2.4.x, short name) */
+       56,             /* Linux (path name) */
+       120,            /* SunOS 5.x, 64-bit */
 };
---->8----

So I made a simple patch.

diff -up file-5.04/src/readelf.c.fix file-5.04/src/readelf.c
--- file-5.04/src/readelf.c.fix 2013-11-30 15:40:12.703462454 +1000
+++ file-5.04/src/readelf.c     2013-11-30 15:43:42.358180691 +1000
@@ -219,6 +219,7 @@ static const size_t prpsoffsets32[] = {
        84,             /* SunOS 5.x (short name) */
 
        44,             /* Linux (command line) */
+        32,             /* PowerPC */
        28,             /* Linux 2.0.36 (short name) */
 
        8,              /* FreeBSD */

I test with that and we get the old rhel5 behaviour back but it turns out this is not consistent with the behaviour for other arches. I think rather than accessing this data from the "file" field of the prpsinfo data whereas convention seems to be to access it from the psargs field.

The correct offset for that appears to be 48 but that complicates the issue as you get overlap with x86 (44).

(gdb) p &nbuf[doff + 48]
$8 = (unsigned char *) 0x7fffffffb904 "./crashme.tsk "

I'm working on a new patch that attempts to resolve that.