* Re: Are ppc*_elf_write_core_note Os-specific? [not found] ` <20160119001819.GB17028@bubble.grove.modra.org> @ 2016-01-19 3:14 ` Alan Modra 2016-01-19 10:26 ` Pedro Alves 2016-01-19 16:41 ` H.J. Lu 0 siblings, 2 replies; 13+ messages in thread From: Alan Modra @ 2016-01-19 3:14 UTC (permalink / raw) To: John Baldwin, Ulrich Weigand; +Cc: binutils, gdb On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: > PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems > only sparc and s390 do so. So PowerPC would need a > hosts/powerpc-linux.h to define them for Linux, with some configury > changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see > about making those changes. > > Note that elf_backend_write_core_note is defined for x86-64, arm and > aarch64 too. The ARM and AARCH64 functions look to be completely > redundant, and I suspect all of them could disappear if we modify the > generic code to handle prstatusx32_t for x86-64. Actually, there is a reason for the ARM and AARCH64 functions. See https://sourceware.org/ml/binutils/2011-10/msg00202.html Note the followup emails too.. So it seems that with the current infrastructure we can either support core file generation on remote (linux) targets, or core file generation on more native targets (freebsd). Alternatively, we'd need to use separate bfd target vectors for linux and freebsd, which can and will cause multiple target matches. Do we really want non-native core file generation? -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 3:14 ` Are ppc*_elf_write_core_note Os-specific? Alan Modra @ 2016-01-19 10:26 ` Pedro Alves 2016-01-19 16:41 ` H.J. Lu 1 sibling, 0 replies; 13+ messages in thread From: Pedro Alves @ 2016-01-19 10:26 UTC (permalink / raw) To: Alan Modra, John Baldwin, Ulrich Weigand; +Cc: binutils, gdb On 01/19/2016 03:14 AM, Alan Modra wrote: > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: >> PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems >> only sparc and s390 do so. So PowerPC would need a >> hosts/powerpc-linux.h to define them for Linux, with some configury >> changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see >> about making those changes. >> >> Note that elf_backend_write_core_note is defined for x86-64, arm and >> aarch64 too. The ARM and AARCH64 functions look to be completely >> redundant, and I suspect all of them could disappear if we modify the >> generic code to handle prstatusx32_t for x86-64. > > Actually, there is a reason for the ARM and AARCH64 functions. > See https://sourceware.org/ml/binutils/2011-10/msg00202.html > Note the followup emails too.. > > So it seems that with the current infrastructure we can either support > core file generation on remote (linux) targets, or core file > generation on more native targets (freebsd). Alternatively, we'd > need to use separate bfd target vectors for linux and freebsd, which > can and will cause multiple target matches. > > Do we really want non-native core file generation? > Yes. IMO, all bfd core file generation and reading should be made independent of host headers. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 3:14 ` Are ppc*_elf_write_core_note Os-specific? Alan Modra 2016-01-19 10:26 ` Pedro Alves @ 2016-01-19 16:41 ` H.J. Lu 2016-01-19 19:01 ` John Baldwin 1 sibling, 1 reply; 13+ messages in thread From: H.J. Lu @ 2016-01-19 16:41 UTC (permalink / raw) To: Alan Modra; +Cc: John Baldwin, Ulrich Weigand, Binutils, GDB On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <amodra@gmail.com> wrote: > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: >> PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems >> only sparc and s390 do so. So PowerPC would need a >> hosts/powerpc-linux.h to define them for Linux, with some configury >> changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see >> about making those changes. >> >> Note that elf_backend_write_core_note is defined for x86-64, arm and >> aarch64 too. The ARM and AARCH64 functions look to be completely >> redundant, and I suspect all of them could disappear if we modify the >> generic code to handle prstatusx32_t for x86-64. > > Actually, there is a reason for the ARM and AARCH64 functions. > See https://sourceware.org/ml/binutils/2011-10/msg00202.html > Note the followup emails too.. > > So it seems that with the current infrastructure we can either support > core file generation on remote (linux) targets, or core file > generation on more native targets (freebsd). Alternatively, we'd > need to use separate bfd target vectors for linux and freebsd, which > can and will cause multiple target matches. > > Do we really want non-native core file generation? > Any changes shouldn't introduce regressions. I don't see why elf_backend_write_core_note can't handle all targets BFD supports since note_type is unique to each OS. BFD just needs to provide proper types independent of host header files, similar to hosts/x86-64linux.h. -- H.J. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 16:41 ` H.J. Lu @ 2016-01-19 19:01 ` John Baldwin 2016-01-19 19:08 ` H.J. Lu 0 siblings, 1 reply; 13+ messages in thread From: John Baldwin @ 2016-01-19 19:01 UTC (permalink / raw) To: H.J. Lu; +Cc: Alan Modra, Ulrich Weigand, Binutils, GDB On Tuesday, January 19, 2016 08:41:05 AM H.J. Lu wrote: > On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <amodra@gmail.com> wrote: > > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: > >> PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems > >> only sparc and s390 do so. So PowerPC would need a > >> hosts/powerpc-linux.h to define them for Linux, with some configury > >> changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see > >> about making those changes. > >> > >> Note that elf_backend_write_core_note is defined for x86-64, arm and > >> aarch64 too. The ARM and AARCH64 functions look to be completely > >> redundant, and I suspect all of them could disappear if we modify the > >> generic code to handle prstatusx32_t for x86-64. > > > > Actually, there is a reason for the ARM and AARCH64 functions. > > See https://sourceware.org/ml/binutils/2011-10/msg00202.html > > Note the followup emails too.. > > > > So it seems that with the current infrastructure we can either support > > core file generation on remote (linux) targets, or core file > > generation on more native targets (freebsd). Alternatively, we'd > > need to use separate bfd target vectors for linux and freebsd, which > > can and will cause multiple target matches. > > > > Do we really want non-native core file generation? > > > > Any changes shouldn't introduce regressions. I don't see why > elf_backend_write_core_note can't handle all targets BFD supports > since note_type is unique to each OS. BFD just needs to provide > proper types independent of host header files, similar to > hosts/x86-64linux.h. Switching on note_type alone (as the current write_core_note methods do) isn't sufficient. Currently bfd writes out notes like NT_PRSTATUS and NT_PRPSINFO with the "CORE" name on multiple platforms, so a (note_name, note_type) tuple also seems insufficient. Are you suggesting to switch on (ELF OSABI, note_type)? That is, supposing you had a hosts/x86-64freebsd.h with a 'struct freebsd_amd64_prstatus' and if hosts/x86-64linux.h had 'struct linux_x86_64_prstatus' (or whatever names are preferred), then the logic in the write_core_note would look something like: switch (get_elf_backend_data (abfd)->elf_osabi) { case ELFOSABI_FREEBSD: { switch (note_type) { case NT_PRSTATUS: struct freebsd_amd64_prstatus prstatus; ... return elfcore_write_note (abfd, ... &prstatus, ...); ... } ... } case ELFOSABI_LINUX: { switch (note_type) { case NT_PRSTATUS: struct linux_x86_64_prstatus prstatus; ... return elfcore_write_note (abfd, ... &prstatus, ...); ... } ... } .. } If so, checking elf_osabi in the current write_core_note functions and falling back to the native "catch-all" if it is not a currently-supported elf_osabi would be sufficient to preserve existing functionality (I think) while allowing other ABIs to either use the catch-all or implement support for desired non-native cores. -- John Baldwin ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 19:01 ` John Baldwin @ 2016-01-19 19:08 ` H.J. Lu 2016-01-19 19:32 ` John Baldwin 0 siblings, 1 reply; 13+ messages in thread From: H.J. Lu @ 2016-01-19 19:08 UTC (permalink / raw) To: John Baldwin; +Cc: Alan Modra, Ulrich Weigand, Binutils, GDB On Tue, Jan 19, 2016 at 10:16 AM, John Baldwin <jhb@freebsd.org> wrote: > On Tuesday, January 19, 2016 08:41:05 AM H.J. Lu wrote: >> On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <amodra@gmail.com> wrote: >> > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: >> >> PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems >> >> only sparc and s390 do so. So PowerPC would need a >> >> hosts/powerpc-linux.h to define them for Linux, with some configury >> >> changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see >> >> about making those changes. >> >> >> >> Note that elf_backend_write_core_note is defined for x86-64, arm and >> >> aarch64 too. The ARM and AARCH64 functions look to be completely >> >> redundant, and I suspect all of them could disappear if we modify the >> >> generic code to handle prstatusx32_t for x86-64. >> > >> > Actually, there is a reason for the ARM and AARCH64 functions. >> > See https://sourceware.org/ml/binutils/2011-10/msg00202.html >> > Note the followup emails too.. >> > >> > So it seems that with the current infrastructure we can either support >> > core file generation on remote (linux) targets, or core file >> > generation on more native targets (freebsd). Alternatively, we'd >> > need to use separate bfd target vectors for linux and freebsd, which >> > can and will cause multiple target matches. >> > >> > Do we really want non-native core file generation? >> > >> >> Any changes shouldn't introduce regressions. I don't see why >> elf_backend_write_core_note can't handle all targets BFD supports >> since note_type is unique to each OS. BFD just needs to provide >> proper types independent of host header files, similar to >> hosts/x86-64linux.h. > > Switching on note_type alone (as the current write_core_note methods do) > isn't sufficient. Currently bfd writes out notes like NT_PRSTATUS and > NT_PRPSINFO with the "CORE" name on multiple platforms, so a > (note_name, note_type) tuple also seems insufficient. Are you suggesting > to switch on (ELF OSABI, note_type)? That is, supposing you had a > hosts/x86-64freebsd.h with a 'struct freebsd_amd64_prstatus' and if > hosts/x86-64linux.h had 'struct linux_x86_64_prstatus' (or whatever names > are preferred), then the logic in the write_core_note would look something > like: > > switch (get_elf_backend_data (abfd)->elf_osabi) > { > case ELFOSABI_FREEBSD: > { > switch (note_type) > { > case NT_PRSTATUS: > struct freebsd_amd64_prstatus prstatus; > ... > return elfcore_write_note (abfd, ... &prstatus, ...); > ... > } > ... > } > case ELFOSABI_LINUX: > { > switch (note_type) > { > case NT_PRSTATUS: > struct linux_x86_64_prstatus prstatus; > ... > return elfcore_write_note (abfd, ... &prstatus, ...); > ... > } > ... > } > .. > } > > If so, checking elf_osabi in the current write_core_note functions and > falling back to the native "catch-all" if it is not a currently-supported > elf_osabi would be sufficient to preserve existing functionality (I think) > while allowing other ABIs to either use the catch-all or implement support > for desired non-native cores. How does GDB tell Linux binary from FreeBSD binary? -- H.J. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 19:08 ` H.J. Lu @ 2016-01-19 19:32 ` John Baldwin 2016-01-19 19:35 ` H.J. Lu 0 siblings, 1 reply; 13+ messages in thread From: John Baldwin @ 2016-01-19 19:32 UTC (permalink / raw) To: H.J. Lu; +Cc: Alan Modra, Ulrich Weigand, Binutils, GDB On Tuesday, January 19, 2016 11:08:23 AM H.J. Lu wrote: > On Tue, Jan 19, 2016 at 10:16 AM, John Baldwin <jhb@freebsd.org> wrote: > > On Tuesday, January 19, 2016 08:41:05 AM H.J. Lu wrote: > >> On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <amodra@gmail.com> wrote: > >> > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: > >> >> PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems > >> >> only sparc and s390 do so. So PowerPC would need a > >> >> hosts/powerpc-linux.h to define them for Linux, with some configury > >> >> changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see > >> >> about making those changes. > >> >> > >> >> Note that elf_backend_write_core_note is defined for x86-64, arm and > >> >> aarch64 too. The ARM and AARCH64 functions look to be completely > >> >> redundant, and I suspect all of them could disappear if we modify the > >> >> generic code to handle prstatusx32_t for x86-64. > >> > > >> > Actually, there is a reason for the ARM and AARCH64 functions. > >> > See https://sourceware.org/ml/binutils/2011-10/msg00202.html > >> > Note the followup emails too.. > >> > > >> > So it seems that with the current infrastructure we can either support > >> > core file generation on remote (linux) targets, or core file > >> > generation on more native targets (freebsd). Alternatively, we'd > >> > need to use separate bfd target vectors for linux and freebsd, which > >> > can and will cause multiple target matches. > >> > > >> > Do we really want non-native core file generation? > >> > > >> > >> Any changes shouldn't introduce regressions. I don't see why > >> elf_backend_write_core_note can't handle all targets BFD supports > >> since note_type is unique to each OS. BFD just needs to provide > >> proper types independent of host header files, similar to > >> hosts/x86-64linux.h. > > > > Switching on note_type alone (as the current write_core_note methods do) > > isn't sufficient. Currently bfd writes out notes like NT_PRSTATUS and > > NT_PRPSINFO with the "CORE" name on multiple platforms, so a > > (note_name, note_type) tuple also seems insufficient. Are you suggesting > > to switch on (ELF OSABI, note_type)? That is, supposing you had a > > hosts/x86-64freebsd.h with a 'struct freebsd_amd64_prstatus' and if > > hosts/x86-64linux.h had 'struct linux_x86_64_prstatus' (or whatever names > > are preferred), then the logic in the write_core_note would look something > > like: > > > > switch (get_elf_backend_data (abfd)->elf_osabi) > > { > > case ELFOSABI_FREEBSD: > > { > > switch (note_type) > > { > > case NT_PRSTATUS: > > struct freebsd_amd64_prstatus prstatus; > > ... > > return elfcore_write_note (abfd, ... &prstatus, ...); > > ... > > } > > ... > > } > > case ELFOSABI_LINUX: > > { > > switch (note_type) > > { > > case NT_PRSTATUS: > > struct linux_x86_64_prstatus prstatus; > > ... > > return elfcore_write_note (abfd, ... &prstatus, ...); > > ... > > } > > ... > > } > > .. > > } > > > > If so, checking elf_osabi in the current write_core_note functions and > > falling back to the native "catch-all" if it is not a currently-supported > > elf_osabi would be sufficient to preserve existing functionality (I think) > > while allowing other ABIs to either use the catch-all or implement support > > for desired non-native cores. > > How does GDB tell Linux binary from FreeBSD binary? For the purposes of choosing a gdbarch to use (and a corresponding set of 'tdep' code to use for parsing register notes, etc.) there are various tests used. The bits I understand are in gdb/osabi.c and test for various things including the elf_osabi field but also .note.ABI-tag notes? I think some (most?) of this detection is to handle historical cases. I'm not sure of the history enough to know which fields are set in modern binaries (and thus used to choose an ABI). The current code to generate a core from within gdb in fbsd-tdep.c overrides the osabi of the bfd before outputting notes: static char * fbsd_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size) { ... /* Put a "FreeBSD" label in the ELF header. */ i_ehdrp = elf_elfheader (obfd); i_ehdrp->e_ident[EI_OSABI] = ELFOSABI_FREEBSD; (This may be unnecessary since the core is created using the same target as the executable file. I will have to try that and see.) This is already used in elfcore_write_xstatereg to determine the note name to use when writing out a register note for XSAVE state: char * elfcore_write_xstatereg (bfd *abfd, char *buf, int *bufsiz, const void *xfpregs, int size) { char *note_name; if (get_elf_backend_data (abfd)->elf_osabi == ELFOSABI_FREEBSD) note_name = "FreeBSD"; else note_name = "LINUX"; return elfcore_write_note (abfd, buf, bufsiz, note_name, NT_X86_XSTATE, xfpregs, size); } linux-tdep.c doesn't appear to explicitly set the osabi, and FreeBSD and Linux are the only targets in gdb that I see that support writing out corefile notes. -- John Baldwin ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 19:32 ` John Baldwin @ 2016-01-19 19:35 ` H.J. Lu 2016-01-19 20:29 ` John Baldwin 0 siblings, 1 reply; 13+ messages in thread From: H.J. Lu @ 2016-01-19 19:35 UTC (permalink / raw) To: John Baldwin; +Cc: Alan Modra, Ulrich Weigand, Binutils, GDB On Tue, Jan 19, 2016 at 11:32 AM, John Baldwin <jhb@freebsd.org> wrote: > On Tuesday, January 19, 2016 11:08:23 AM H.J. Lu wrote: >> On Tue, Jan 19, 2016 at 10:16 AM, John Baldwin <jhb@freebsd.org> wrote: >> > On Tuesday, January 19, 2016 08:41:05 AM H.J. Lu wrote: >> >> On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <amodra@gmail.com> wrote: >> >> > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: >> >> >> PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems >> >> >> only sparc and s390 do so. So PowerPC would need a >> >> >> hosts/powerpc-linux.h to define them for Linux, with some configury >> >> >> changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see >> >> >> about making those changes. >> >> >> >> >> >> Note that elf_backend_write_core_note is defined for x86-64, arm and >> >> >> aarch64 too. The ARM and AARCH64 functions look to be completely >> >> >> redundant, and I suspect all of them could disappear if we modify the >> >> >> generic code to handle prstatusx32_t for x86-64. >> >> > >> >> > Actually, there is a reason for the ARM and AARCH64 functions. >> >> > See https://sourceware.org/ml/binutils/2011-10/msg00202.html >> >> > Note the followup emails too.. >> >> > >> >> > So it seems that with the current infrastructure we can either support >> >> > core file generation on remote (linux) targets, or core file >> >> > generation on more native targets (freebsd). Alternatively, we'd >> >> > need to use separate bfd target vectors for linux and freebsd, which >> >> > can and will cause multiple target matches. >> >> > >> >> > Do we really want non-native core file generation? >> >> > >> >> >> >> Any changes shouldn't introduce regressions. I don't see why >> >> elf_backend_write_core_note can't handle all targets BFD supports >> >> since note_type is unique to each OS. BFD just needs to provide >> >> proper types independent of host header files, similar to >> >> hosts/x86-64linux.h. >> > >> > Switching on note_type alone (as the current write_core_note methods do) >> > isn't sufficient. Currently bfd writes out notes like NT_PRSTATUS and >> > NT_PRPSINFO with the "CORE" name on multiple platforms, so a >> > (note_name, note_type) tuple also seems insufficient. Are you suggesting >> > to switch on (ELF OSABI, note_type)? That is, supposing you had a >> > hosts/x86-64freebsd.h with a 'struct freebsd_amd64_prstatus' and if >> > hosts/x86-64linux.h had 'struct linux_x86_64_prstatus' (or whatever names >> > are preferred), then the logic in the write_core_note would look something >> > like: >> > >> > switch (get_elf_backend_data (abfd)->elf_osabi) >> > { >> > case ELFOSABI_FREEBSD: >> > { >> > switch (note_type) >> > { >> > case NT_PRSTATUS: >> > struct freebsd_amd64_prstatus prstatus; >> > ... >> > return elfcore_write_note (abfd, ... &prstatus, ...); >> > ... >> > } >> > ... >> > } >> > case ELFOSABI_LINUX: >> > { >> > switch (note_type) >> > { >> > case NT_PRSTATUS: >> > struct linux_x86_64_prstatus prstatus; >> > ... >> > return elfcore_write_note (abfd, ... &prstatus, ...); >> > ... >> > } >> > ... >> > } >> > .. >> > } >> > >> > If so, checking elf_osabi in the current write_core_note functions and >> > falling back to the native "catch-all" if it is not a currently-supported >> > elf_osabi would be sufficient to preserve existing functionality (I think) >> > while allowing other ABIs to either use the catch-all or implement support >> > for desired non-native cores. >> >> How does GDB tell Linux binary from FreeBSD binary? > > For the purposes of choosing a gdbarch to use (and a corresponding set of > 'tdep' code to use for parsing register notes, etc.) there are various > tests used. The bits I understand are in gdb/osabi.c and test for various > things including the elf_osabi field but also .note.ABI-tag notes? I think > some (most?) of this detection is to handle historical cases. I'm not sure > of the history enough to know which fields are set in modern binaries (and > thus used to choose an ABI). > > The current code to generate a core from within gdb in fbsd-tdep.c overrides > the osabi of the bfd before outputting notes: > > static char * > fbsd_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size) > { > ... > > /* Put a "FreeBSD" label in the ELF header. */ > i_ehdrp = elf_elfheader (obfd); > i_ehdrp->e_ident[EI_OSABI] = ELFOSABI_FREEBSD; > > (This may be unnecessary since the core is created using the same target as > the executable file. I will have to try that and see.) > > This is already used in elfcore_write_xstatereg to determine the note name to > use when writing out a register note for XSAVE state: > > char * > elfcore_write_xstatereg (bfd *abfd, char *buf, int *bufsiz, > const void *xfpregs, int size) > { > char *note_name; > if (get_elf_backend_data (abfd)->elf_osabi == ELFOSABI_FREEBSD) > note_name = "FreeBSD"; > else > note_name = "LINUX"; > return elfcore_write_note (abfd, buf, bufsiz, > note_name, NT_X86_XSTATE, xfpregs, size); > } > > linux-tdep.c doesn't appear to explicitly set the osabi, and FreeBSD and > Linux are the only targets in gdb that I see that support writing out corefile > notes. > We could do 1. Pass OS selection from GDB to BFD. Or 2. Factor out OS selection from GDB and put it into GDB so that it can be used by both GDB and BFD. -- H.J. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 19:35 ` H.J. Lu @ 2016-01-19 20:29 ` John Baldwin 2016-01-19 20:54 ` Pedro Alves 0 siblings, 1 reply; 13+ messages in thread From: John Baldwin @ 2016-01-19 20:29 UTC (permalink / raw) To: H.J. Lu; +Cc: Alan Modra, Ulrich Weigand, Binutils, GDB On Tuesday, January 19, 2016 11:35:33 AM H.J. Lu wrote: > On Tue, Jan 19, 2016 at 11:32 AM, John Baldwin <jhb@freebsd.org> wrote: > > On Tuesday, January 19, 2016 11:08:23 AM H.J. Lu wrote: > >> On Tue, Jan 19, 2016 at 10:16 AM, John Baldwin <jhb@freebsd.org> wrote: > >> > On Tuesday, January 19, 2016 08:41:05 AM H.J. Lu wrote: > >> >> On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <amodra@gmail.com> wrote: > >> >> > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: > >> >> >> PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems > >> >> >> only sparc and s390 do so. So PowerPC would need a > >> >> >> hosts/powerpc-linux.h to define them for Linux, with some configury > >> >> >> changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see > >> >> >> about making those changes. > >> >> >> > >> >> >> Note that elf_backend_write_core_note is defined for x86-64, arm and > >> >> >> aarch64 too. The ARM and AARCH64 functions look to be completely > >> >> >> redundant, and I suspect all of them could disappear if we modify the > >> >> >> generic code to handle prstatusx32_t for x86-64. > >> >> > > >> >> > Actually, there is a reason for the ARM and AARCH64 functions. > >> >> > See https://sourceware.org/ml/binutils/2011-10/msg00202.html > >> >> > Note the followup emails too.. > >> >> > > >> >> > So it seems that with the current infrastructure we can either support > >> >> > core file generation on remote (linux) targets, or core file > >> >> > generation on more native targets (freebsd). Alternatively, we'd > >> >> > need to use separate bfd target vectors for linux and freebsd, which > >> >> > can and will cause multiple target matches. > >> >> > > >> >> > Do we really want non-native core file generation? > >> >> > > >> >> > >> >> Any changes shouldn't introduce regressions. I don't see why > >> >> elf_backend_write_core_note can't handle all targets BFD supports > >> >> since note_type is unique to each OS. BFD just needs to provide > >> >> proper types independent of host header files, similar to > >> >> hosts/x86-64linux.h. > >> > > >> > Switching on note_type alone (as the current write_core_note methods do) > >> > isn't sufficient. Currently bfd writes out notes like NT_PRSTATUS and > >> > NT_PRPSINFO with the "CORE" name on multiple platforms, so a > >> > (note_name, note_type) tuple also seems insufficient. Are you suggesting > >> > to switch on (ELF OSABI, note_type)? That is, supposing you had a > >> > hosts/x86-64freebsd.h with a 'struct freebsd_amd64_prstatus' and if > >> > hosts/x86-64linux.h had 'struct linux_x86_64_prstatus' (or whatever names > >> > are preferred), then the logic in the write_core_note would look something > >> > like: > >> > > >> > switch (get_elf_backend_data (abfd)->elf_osabi) > >> > { > >> > case ELFOSABI_FREEBSD: > >> > { > >> > switch (note_type) > >> > { > >> > case NT_PRSTATUS: > >> > struct freebsd_amd64_prstatus prstatus; > >> > ... > >> > return elfcore_write_note (abfd, ... &prstatus, ...); > >> > ... > >> > } > >> > ... > >> > } > >> > case ELFOSABI_LINUX: > >> > { > >> > switch (note_type) > >> > { > >> > case NT_PRSTATUS: > >> > struct linux_x86_64_prstatus prstatus; > >> > ... > >> > return elfcore_write_note (abfd, ... &prstatus, ...); > >> > ... > >> > } > >> > ... > >> > } > >> > .. > >> > } > >> > > >> > If so, checking elf_osabi in the current write_core_note functions and > >> > falling back to the native "catch-all" if it is not a currently-supported > >> > elf_osabi would be sufficient to preserve existing functionality (I think) > >> > while allowing other ABIs to either use the catch-all or implement support > >> > for desired non-native cores. > >> > >> How does GDB tell Linux binary from FreeBSD binary? > > > > For the purposes of choosing a gdbarch to use (and a corresponding set of > > 'tdep' code to use for parsing register notes, etc.) there are various > > tests used. The bits I understand are in gdb/osabi.c and test for various > > things including the elf_osabi field but also .note.ABI-tag notes? I think > > some (most?) of this detection is to handle historical cases. I'm not sure > > of the history enough to know which fields are set in modern binaries (and > > thus used to choose an ABI). > > > > The current code to generate a core from within gdb in fbsd-tdep.c overrides > > the osabi of the bfd before outputting notes: > > > > static char * > > fbsd_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size) > > { > > ... > > > > /* Put a "FreeBSD" label in the ELF header. */ > > i_ehdrp = elf_elfheader (obfd); > > i_ehdrp->e_ident[EI_OSABI] = ELFOSABI_FREEBSD; > > > > (This may be unnecessary since the core is created using the same target as > > the executable file. I will have to try that and see.) > > > > This is already used in elfcore_write_xstatereg to determine the note name to > > use when writing out a register note for XSAVE state: > > > > char * > > elfcore_write_xstatereg (bfd *abfd, char *buf, int *bufsiz, > > const void *xfpregs, int size) > > { > > char *note_name; > > if (get_elf_backend_data (abfd)->elf_osabi == ELFOSABI_FREEBSD) > > note_name = "FreeBSD"; > > else > > note_name = "LINUX"; > > return elfcore_write_note (abfd, buf, bufsiz, > > note_name, NT_X86_XSTATE, xfpregs, size); > > } > > > > linux-tdep.c doesn't appear to explicitly set the osabi, and FreeBSD and > > Linux are the only targets in gdb that I see that support writing out corefile > > notes. > > > > We could do > > 1. Pass OS selection from GDB to BFD. Or > 2. Factor out OS selection from GDB and put it into GDB so that it > can be used by both GDB and BFD. I can work with whatever approach you think is best. Note that some of the logic in osabi.c is to deal with older binaries (a.out, older ELF when different "branding" strategies were used, etc.). For the purposes of generating new binaries, checking elf_osabi in the ELF-specific core code as in elfcore_write_xstatereg might be sufficient for 1. For 2., the existing logic is used to choose a specific gdbarch (which I think would be akin to detecting a specific BFD target to use). You could already perhaps do this without additional changes if the write_core_note override were a per-target override (e.g. x86_64_elf64_fbsd_vec could have a FreeBSD-specific write_core_note). However, I don't generally see Linux-specific targets (which I think you would want to hold Linux-specific write_core_note's so that the "generic" targets did not provide overrides, though only architectures that want a custom write_core_note would need that). My understanding of BFD targets is quite limited however, and it maybe that write_core_note is already a target method (or it might be that write_core_note in a BFD target would be a layering violation). -- John Baldwin ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 20:29 ` John Baldwin @ 2016-01-19 20:54 ` Pedro Alves 2016-01-19 21:20 ` H.J. Lu 0 siblings, 1 reply; 13+ messages in thread From: Pedro Alves @ 2016-01-19 20:54 UTC (permalink / raw) To: John Baldwin, H.J. Lu; +Cc: Alan Modra, Ulrich Weigand, Binutils, GDB Can this be made to work along the lines of 70a38d42c5b3 ? Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 20:54 ` Pedro Alves @ 2016-01-19 21:20 ` H.J. Lu 2016-01-19 21:24 ` H.J. Lu 2016-01-19 22:52 ` Pedro Alves 0 siblings, 2 replies; 13+ messages in thread From: H.J. Lu @ 2016-01-19 21:20 UTC (permalink / raw) To: Pedro Alves; +Cc: John Baldwin, Alan Modra, Ulrich Weigand, Binutils, GDB On Tue, Jan 19, 2016 at 12:54 PM, Pedro Alves <palves@redhat.com> wrote: > Can this be made to work along the lines of 70a38d42c5b3 ? > Probably. See: https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=0b1b9b0935de0f6d97540d80dfb698444cb07072 -- H.J. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 21:20 ` H.J. Lu @ 2016-01-19 21:24 ` H.J. Lu 2016-01-19 22:52 ` Pedro Alves 1 sibling, 0 replies; 13+ messages in thread From: H.J. Lu @ 2016-01-19 21:24 UTC (permalink / raw) To: Pedro Alves; +Cc: John Baldwin, Alan Modra, Ulrich Weigand, Binutils, GDB On Tue, Jan 19, 2016 at 1:20 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Tue, Jan 19, 2016 at 12:54 PM, Pedro Alves <palves@redhat.com> wrote: >> Can this be made to work along the lines of 70a38d42c5b3 ? >> > > Probably. See: > > https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=0b1b9b0935de0f6d97540d80dfb698444cb07072 > > -- > H.J. See users/hjl/gcore branch. -- H.J. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 21:20 ` H.J. Lu 2016-01-19 21:24 ` H.J. Lu @ 2016-01-19 22:52 ` Pedro Alves 2016-01-20 3:07 ` Alan Modra 1 sibling, 1 reply; 13+ messages in thread From: Pedro Alves @ 2016-01-19 22:52 UTC (permalink / raw) To: H.J. Lu; +Cc: John Baldwin, Alan Modra, Ulrich Weigand, Binutils, GDB On 01/19/2016 09:20 PM, H.J. Lu wrote: > On Tue, Jan 19, 2016 at 12:54 PM, Pedro Alves <palves@redhat.com> wrote: >> Can this be made to work along the lines of 70a38d42c5b3 ? >> > > Probably. See: > > https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=0b1b9b0935de0f6d97540d80dfb698444cb07072 > The thing is that GDB always knows the target ABI/OS it wants the core note to be generated for, so there should be no need to go through the bfd target vector to generate an OS-specific note, or to stuff everything through a crippling varargs interface such as elf_backend_write_core_note's. Instead, bfd can export OS-specific variants of the note generation functions, and GDB can call those directly. By avoiding the varargs-style strangling of elf_backend_write_core_note, it's also MUCH easier to pass down note-specific info. The original motivation of 70a38d42c5b3 (elfcore_write_linux_prpsinfo*) was so that we could fill in all fields of the Linux prpsinfo structure. (Note how elfcore_write_prpsinfo only takes a few parameters; it's missing a lot of others bits.) The gdb-side counterpart of 70a38d42c5b3 is b3ac9c77560a. All the Linux-specific NT_PRPSINFO handling in the different elf_backend_write_core_note implementations in bfd are dead code, I think, since GDB always calls elfcore_write_linux_prpsinfo* directly, and only GDB calls the elfcore_write_pr* functions. I think that ideally we'd give the same treatment to elfcore_write_prstatus; it's just that nobody ever did the leg work. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Are ppc*_elf_write_core_note Os-specific? 2016-01-19 22:52 ` Pedro Alves @ 2016-01-20 3:07 ` Alan Modra 0 siblings, 0 replies; 13+ messages in thread From: Alan Modra @ 2016-01-20 3:07 UTC (permalink / raw) To: Pedro Alves; +Cc: H.J. Lu, John Baldwin, Ulrich Weigand, Binutils, GDB On Tue, Jan 19, 2016 at 10:52:33PM +0000, Pedro Alves wrote: > I think that ideally we'd give the same treatment to > elfcore_write_prstatus; it's just that nobody ever did the leg work. Some leg work. For all linux targets except mips n32 which has a 64-bit pr_sigpend and pr_sighold, we have struct elf_prstatus { struct elf_siginfo pr_info; short int pr_cursig; unsigned long int pr_sigpend; unsigned long int pr_sighold; __pid_t pr_pid; __pid_t pr_ppid; __pid_t pr_pgrp; __pid_t pr_sid; struct timeval pr_utime; struct timeval pr_stime; struct timeval pr_cutime; struct timeval pr_cstime; elf_gregset_t pr_reg; int pr_fpvalid; }; struct elf_siginfo is three ints, struct timeval is two longs except for sparc where tv_usec is an int, __pid_t is an int. elf_gregset_t of course varies. Unless I'm missing some odd target struct alignment rule, I think that means linux needs a 32-bit and 64-bit variant of elfcore_write_linux_prprstatus with parameters similar to elfcore_write_linux_prpsinfo*, and special cases for mips n32 and sparc64. I'd assume gdb's new elf_internal_linux_prstatus struct would contain a pointer to and size of regs in target format. Host format would be messy since some 64-bit targets have the odd 32-bit reg hidden away in elf_gregset_t. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-01-20 3:07 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1736699.V7zq9VJIrx@ralph.baldwin.cx> [not found] ` <20160119001819.GB17028@bubble.grove.modra.org> 2016-01-19 3:14 ` Are ppc*_elf_write_core_note Os-specific? Alan Modra 2016-01-19 10:26 ` Pedro Alves 2016-01-19 16:41 ` H.J. Lu 2016-01-19 19:01 ` John Baldwin 2016-01-19 19:08 ` H.J. Lu 2016-01-19 19:32 ` John Baldwin 2016-01-19 19:35 ` H.J. Lu 2016-01-19 20:29 ` John Baldwin 2016-01-19 20:54 ` Pedro Alves 2016-01-19 21:20 ` H.J. Lu 2016-01-19 21:24 ` H.J. Lu 2016-01-19 22:52 ` Pedro Alves 2016-01-20 3:07 ` Alan Modra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).