This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [PATCH, MIPS] Extract PID from core dump file
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Djordje Todorovic <djordje dot todorovic at rt-rk dot com>
- Cc: <binutils at sourceware dot org>, <gdb at sourceware dot org>, <nemanja dot popov at rt-rk dot com>, <nikola dot prica at rt-rk dot com>, <petar dot jovanovic at rt-rk dot com>, <asowda at cisco dot com>, <ibaev at cisco dot com>
- Date: Wed, 16 Aug 2017 11:42:08 +0100
- Subject: Re: [PATCH, MIPS] Extract PID from core dump file
- Authentication-results: sourceware.org; auth=none
- References: <593520EC.3050803@rt-rk.com> <alpine.DEB.2.00.1706160019330.23046@tp.orcam.me.uk> <5947CFF6.2070703@rt-rk.com>
Hi Djordje,
Apologies for the long RTT. Cc-ing `gdb' as this affects GDB processing.
> On MIPS platforms, PID information was not correctly propagated from core dump
> file to internal GDB structures. This patch fixes that behavior.
>
> The bug was found while trying to read TLS variable from core dump file on
> MIPS platforms, but it was not able because GDB needs correct PID information
> in order to do that.
Would you be able to give me a recipe to reproduce a scenario where the
effect of actions taken is not as expected? I'd like to have it covered
by a GDB test suite case if possible.
> This change is tested on MIPS64R2 board with o32, n32 and n64 executables.
> Test program is forced to crash in order to generate core file. Core file is
> loaded into GDB and bfd structure is checked if it has correct PID value, the
> same value executable had before crash.
AFAICT however GDB prefers LWPID if available, so while I agree that
technically we ought to retrieve PID as well, in reality it shouldn't
really matter. Having a test case demonstrating a user-visible effect
would indeed help.
> Currently I don't have copyright assignment. Couple a weeks ago my company
> initiated process of getting copyright assignment but with no response so
> far.
Any update on progress? While I think your change can be considered
small enough not to require a copyright assignment for acceptance, it
would be preferable if you had it.
> diff --git a/bfd/elf32-mips.c b/bfd/elf32-mips.c
> index 8c1a68eb..9ec2818 100644
> --- a/bfd/elf32-mips.c
> +++ b/bfd/elf32-mips.c
> @@ -2353,6 +2353,8 @@ elf32_mips_grok_psinfo (bfd *abfd, Elf_Internal_Note
> *note)
> return FALSE;
>
> case 128: /* Linux/MIPS elf_prpsinfo */
> + elf_tdata (abfd)->core->pid
> + = bfd_get_32 (abfd, note->descdata + 24);
> elf_tdata (abfd)->core->program
> = _bfd_elfcore_strndup (abfd, note->descdata + 32, 16);
> elf_tdata (abfd)->core->command
The offset isn't right however, you're fetching the process group ID
rather than the process ID:
(gdb) ptype struct elf_prpsinfo
type = struct elf_prpsinfo {
char pr_state;
char pr_sname;
char pr_zomb;
char pr_nice;
unsigned long pr_flag;
__kernel_uid_t pr_uid;
__kernel_gid_t pr_gid;
pid_t pr_pid;
pid_t pr_ppid;
pid_t pr_pgrp;
pid_t pr_sid;
char pr_fname[16];
char pr_psargs[80];
}
(gdb) print /d &((struct elf_prpsinfo *)0)->pr_pid
$1 = 16
(gdb) print /d &((struct elf_prpsinfo *)0)->pr_pgrp
$2 = 24
(gdb)
Same with n32. The n64 variant is OK.
Maciej