From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15361 invoked by alias); 19 Jan 2016 19:35:38 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 15341 invoked by uid 89); 19 Jan 2016 19:35:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=*abfd, *obfd, *note_size, elf_elfheader X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-qg0-f43.google.com Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 19 Jan 2016 19:35:35 +0000 Received: by mail-qg0-f43.google.com with SMTP id o11so587994509qge.2; Tue, 19 Jan 2016 11:35:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4BW9HptQeERPnKBq1LwOeXgVgS6heQhJsHTfFW8BF+w=; b=MGhAyMDzFvT5mXbxZ8srXNT2YtqON3e+a9KCg9rBCY9a7Abd3g2daG1rF9VXPnEXey wyTzYsAtp13ASHkkmThOKFXYWvOYHBsjp1teIdbeXFgBN3cknw5IZJtgxoMKxqt8y2uk aRuQ0lsDnT6ntr3wxG92OdRSje8ZQF2kb7PpMHntreyw+qsfTV5JX2FFIl9896OkpiYC 4QRekLdVaW2guMJOWCeahJg3WWY+YQDALhgqPSanbHQy/zlTlSh+GxCQ0jrdfHp8G5TE eVqfTmmabtK5ANjom1CmLYwcsXlGDlRpR6Syjw6SBAYab/sKFRwxeM9zoF+cKKQStYOv e4nQ== X-Gm-Message-State: AG10YOQdx5TPjHPQzzqTUqx7SxZIky+TnGrxT/HIRxOjRULGtiNneEx4P1IaoPkAirw0PAUSFBr51/iyeI2TGw== MIME-Version: 1.0 X-Received: by 10.140.104.100 with SMTP id z91mr6788270qge.26.1453232133296; Tue, 19 Jan 2016 11:35:33 -0800 (PST) Received: by 10.55.215.6 with HTTP; Tue, 19 Jan 2016 11:35:33 -0800 (PST) In-Reply-To: <1866442.mSXmZIT7y1@ralph.baldwin.cx> References: <1736699.V7zq9VJIrx@ralph.baldwin.cx> <3209137.BFgmUDYLhZ@ralph.baldwin.cx> <1866442.mSXmZIT7y1@ralph.baldwin.cx> Date: Tue, 19 Jan 2016 19:35:00 -0000 Message-ID: Subject: Re: Are ppc*_elf_write_core_note Os-specific? From: "H.J. Lu" To: John Baldwin Cc: Alan Modra , Ulrich Weigand , Binutils , GDB Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-01/txt/msg00036.txt.bz2 On Tue, Jan 19, 2016 at 11:32 AM, John Baldwin 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 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 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.