From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47057 invoked by alias); 15 Jul 2019 08:56:45 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 47047 invoked by uid 89); 15 Jul 2019 08:56:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-20.8 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=mutt, mails X-Spam-Status: No, score=-20.8 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: smtp2200-217.mail.aliyun.com Received: from smtp2200-217.mail.aliyun.com (HELO smtp2200-217.mail.aliyun.com) (121.197.200.217) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Jul 2019 08:56:42 +0000 X-Alimail-AntiSpam:AC=CONTINUE;BC=0.07454418|-1;CH=green;DM=CONTINUE|CONTINUE|true|0.0620259-0.00199234-0.935982;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03307;MF=han_mao@c-sky.com;NM=1;PH=DS;RN=2;RT=2;SR=0;TI=SMTPD_---.ExnW0Th_1563180999; Received: from localhost(mailfrom:han_mao@c-sky.com fp:SMTPD_---.ExnW0Th_1563180999) by smtp.aliyun-inc.com(10.147.40.200); Mon, 15 Jul 2019 16:56:39 +0800 Date: Mon, 15 Jul 2019 08:56:00 -0000 From: Mao Han To: mark@klomp.org Cc: elfutils-devel@sourceware.org Subject: Re: [[RESEND & PING]PATCH V3 1/1] Add backend support for C-SKY Message-ID: <20190715085506.GA14402@vmh-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2019-q3/txt/msg00051.txt.bz2 Hi Mark, I can't find the origin mail thread in my mailbox, as my mutt can only keep the newest 5000 mails. So I just reply in a new thread. > > I've generated binaries/core with an upstream toolchain, however the > > divzero testcase doesn't cause any coredump, so I used a zeroptr > > testcase instead. > > https://github.com/c-sky/test-result/blob/master/elfutils/zeroptr > > https://github.com/c-sky/test-result/raw/master/elfutils/core.zeroptr > > The zeroptr binary does seem to be a real EM_CSKY one now. > But the core.zeroptr still seems to be a core file for EM_RCE (or > EM_MCORE). > > I assume the kernel generated the core file and it doesn't yet produce > real EM_CSKY ELF core files? > > If you have any other way to generate a core file (maybe gdb/gcore can > do it?) that would be really helpful. The ELF_ARCH was defined as 39 inside linux kernel(before 4.20), so the the core file generated was EM_RCE. I'v regenerated the core file with ELF_ARCH defined as 252: https://github.com/c-sky/test-result/blob/master/elfutils/zeroptr https://github.com/c-sky/test-result/raw/master/elfutils/core.zeroptr We have extended our core dump reg set last year, linux kernel have upstreamed this change, but the gdb does not. I'v only got an old released toolchain(EM_RCE) and the upstream toolchain(out of date reg set) in my enviroment, so I can't generate/verify EM_CSKY core file with any toolchain I have. > > 5. run-reverse-sections-self.sh > > elfcopy --reverse-offs dose not work properly on C-SKY object file, > > seems not related to arch specific code. > > size.o before copy: > > https://github.com/c-sky/test-result/blob/master/elfutils/size.o > > size.o.rev after copy: > > https://github.com/c-sky/test-result/blob/master/elfutils/size.o.rev > > This might be because these files are also EM_RCE instead of EM_CSKY. > But most likely it was because there was a bug in the testcase. > Make sure you have commit d08c68 tests: elfcopy --reverse-offs should > only swap sections next to each other. > > It looks like in the original the .csky.attributes and .shstrtab are > not really next to each other (they have consecutive section numbers, > but the file offsets are far apart). And that could have fooled the > original test case. > > Please make sure you have the above commit/fix in your tree and see if > it passes then. This case can pass with the newest elfutils. I believe it is fixed with commit d08c68. > OK. > > > +RELOC_TYPE (PCRELIMM8BY4, REL) > > +RELOC_TYPE (PCRELIMM11BY2, REL) > > Do we want these two? They seem to be v1 only. > > > +RELOC_TYPE (PCREL32, REL|DYN) > > This is probably wanted, but the CPU ABI document has it listed as ??. > > > +RELOC_TYPE (PCRELJSR_IMM11BY2, REL) > > Also v1 only? > > > +RELOC_TYPE (GOTOFF, REL) > > +RELOC_TYPE (GOTPC, REL) > > +RELOC_TYPE (GOT32, REL) > > +RELOC_TYPE (PLT32, REL) > > +RELOC_TYPE (ADDRGOT, REL) > > +RELOC_TYPE (ADDRPLT, REL) > > v1 only? > > > R_CKCORE_GOTOFF_IMM18 is missing, but it is also missing in elf.h. > > > +RELOC_TYPE (GOT_IMM18BY4, REL) > > +RELOC_TYPE (PLT_IMM18BY4, REL) > > We can list the v1 variants also, their numbers don't overlap. > Just checking it is done deliberately. If they can never occur in v2 > ELF binaries I would leave them out. The content of the ABI manual is quite old, binutils souce code seems much reliable to refer to. binutils/bfd/elf32-csky.c says, only three relocations are abiv1 exclusive: R_CKCORE_PCREL_JSR_IMM11BY2 R_CKCORE_PCREL_IMM8BY4 R_CKCORE_PCREL_IMM11BY2 The following relocations can occur in v2 ELF binaries. R_CKCORE_PCREL32 R_CKCORE_GOTOFF R_CKCORE_GOTPC R_CKCORE_GOT32 R_CKCORE_PLT32 R_CKCORE_ADDRGOT R_CKCORE_ADDRPLT R_CKCORE_GOTOFF_IMM18 seems unused at present. > On Thu, 2019-07-11 at 11:19 +0800, Mao Han wrote: > > On Thu, Jul 11, 2019 at 12:11:17AM +0200, Mark Wielaard wrote: > > > As far as I can see this is like a SHT_GNU_ATTRIBUTES or > > > SHT_ARM_ATTRIBUTES section. If so, you will also want something > > > like: > > > > > > diff --git a/src/readelf.c b/src/readelf.c > > > index cda7c93..8017dc4 100644 > > > --- a/src/readelf.c > > > +++ b/src/readelf.c > > > @@ -3571,7 +3571,9 @@ print_attributes (Ebl *ebl, const GElf_Ehdr > > > *ehdr) > > > > > > if (shdr == NULL || (shdr->sh_type != SHT_GNU_ATTRIBUTES > > > && (shdr->sh_type != SHT_ARM_ATTRIBUTES > > > - || ehdr->e_machine != EM_ARM))) > > > + || ehdr->e_machine != EM_ARM) > > > + && (shdr->sh_type != SHT_CSKY_ATTRIBUTES > > > + || ehdr->e_machine != EM_CSKY))) > > > continue; > > > > > > printf (gettext ("\ > > > > > > And then hook check_object_attribute to display any CSKY specific > > > attribute names/values. > > > > Ok, I'll add check for C-SKY here. > > BTW. I couldn't find what generates the SHT_CSKY_ATTRIBUTES or what the > defined attribute constants are. Are they documented somewhere? These attributes including cpu name and some other ISA related descriptions. Some thing like: CSKY_ARCH_NAME: "ck810" CSKY_CPU_NAME: "ck810f" CSKY_ISA_FLAG: 0x12345678 CSKY_ISA_EXT_FLAG: 5 They are not documented yet. I'v ask the person who is responsible for these to update the ABI documents, but I think it will take a quite long time for them to do that. They are quite busy at present. Thanks, Mao Han