Re: [[RESEND & PING]PATCH V3 1/1] Add backend support for C-SKY

[Mao Han <han_mao@c-sky.com>]

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