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
