[[RESEND & PING]PATCH V3 1/1] Add backend support for C-SKY
Mon Jul 15 08:56:00 GMT 2019
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
> 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:
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.
> > +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:
The following relocations can occur in v2 ELF binaries.
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:
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.
More information about the Elfutils-devel