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

[Mao Han]

On Thu, Jul 11, 2019 at 03:36:03PM +0200, Mark Wielaard wrote:
> > the EM_CSKY_OLD equals to 39. We have changed the EM number to 252 in
> > our newly released toolchain with compatibility to EM_CSKY_OLD.
> > See binutils/include/elf/common.h:
> > /* C-SKY historically used 39, the same value as MCORE, from which
> > the
> >architecture was derived.  */
> > #define EM_CSKY_OLD EM_MCORE
> 
> Aha. But that is unfortunate on 2 levels. First EM_MCORE isn't an
> official e_machine name. The value 39 is associated with EM_RCE for the
> Morotola RCE. I assume those are the same thing?
> 
Yes, they are the same thing.

#define EM_MCORE 39 /* Motorola M*Core */ /* May also be taken by 
Fujitsu MMA */
#define EM_RCE   39 /* Old name for MCore */

> Second, it makes it hard to check the elfutils backend since you'll
> have to comment out all EM_RCE usage, and change the EM_CSKY to the old
> value.
> 
> Do you have any binaries/core files generated by an upstream toolchain
> that uses the assigned ELF values? That would be really helpful running
> some tests.
>

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

Thanks,
Mao Han 

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

[Mark Wielaard]

On Fri, 2019-07-12 at 19:22 +0800, Mao Han wrote:
> 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.

Thanks,

Mark

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

[Mark Wielaard]

On Mon, 2019-06-03 at 16:16 +0800, Mao Han wrote:
> 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.

Thanks,

Mark

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

[Mark Wielaard]

On Mon, 2019-06-03 at 16:16 +0800, Mao Han wrote:
> diff --git a/backends/csky_reloc.def b/backends/csky_reloc.def
> new file mode 100644
> index 000..1108f0c
> --- /dev/null
> +++ b/backends/csky_reloc.def
> @@ -0,0 +1,86 @@
> +/* List the relocation types for csky.  -*- C -*-
> +   Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +   This file is part of elfutils.
> +
> +   This file is free software; you can redistribute it and/or modify
> +   it under the terms of either
> +
> + * the GNU Lesser General Public License as published by the Free
> +   Software Foundation; either version 3 of the License, or (at
> +   your option) any later version
> +
> +   or
> +
> + * the GNU General Public License as published by the Free
> +   Software Foundation; either version 2 of the License, or (at
> +   your option) any later version
> +
> +   or both in parallel, as here.
> +
> +   elfutils is distributed in the hope that it will be useful, but
> +   WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   General Public License for more details.
> +
> +   You should have received copies of the GNU General Public License and
> +   the GNU Lesser General Public License along with this program.  If
> +   not, see .  */
> +
> +/* NAME,   REL|EXEC|DYN*/
> +
> +
> +RELOC_TYPE (NONE,  REL|EXEC|DYN)
> +RELOC_TYPE (ADDR32,REL|EXEC|DYN)

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 (RELATIVE,  EXEC|DYN)
> +RELOC_TYPE (COPY,  EXEC|DYN)
> +RELOC_TYPE (GLOB_DAT,  EXEC|DYN)
> +RELOC_TYPE (JUMP_SLOT, EXEC|DYN)

OK.

> +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?

> +RELOC_TYPE (PCREL_IMM26BY2,REL)
> +RELOC_TYPE (PCREL_IMM16BY2,REL)
> +RELOC_TYPE (PCREL_IMM16BY4,REL)
> +RELOC_TYPE (PCREL_IMM10BY2,REL)
> +RELOC_TYPE (PCREL_IMM10BY4,REL)
> +RELOC_TYPE (ADDR_HI16, REL|DYN)
> +RELOC_TYPE (ADDR_LO16, REL|DYN)
> +RELOC_TYPE (GOTPC_HI16,REL)
> +RELOC_TYPE (GOTPC_LO16,REL)
> +RELOC_TYPE (GOTOFF_HI16,   REL)
> +RELOC_TYPE (GOTOFF_LO16,   REL)
> +RELOC_TYPE (GOT12, REL)
> +RELOC_TYPE (GOT_HI16,  REL)
> +RELOC_TYPE (GOT_LO16,  REL)
> +RELOC_TYPE (PLT12, REL)
> +RELOC_TYPE (PLT_HI16,  REL)
> +RELOC_TYPE (PLT_LO16,  REL)
> +RELOC_TYPE (ADDRGOT_HI16,  REL)
> +RELOC_TYPE (ADDRGOT_LO16,  REL)
> +RELOC_TYPE (ADDRPLT_HI16,  REL)
> +RELOC_TYPE (ADDRPLT_LO16,  REL)
> +RELOC_TYPE (PCREL_JSR_IMM26BY2,REL|DYN)
> +RELOC_TYPE (TOFFSET_LO16,  REL)
> +RELOC_TYPE (DOFFSET_LO16,  REL)
> +RELOC_TYPE (PCREL_IMM18BY2,REL)
> +RELOC_TYPE (DOFFSET_IMM18, REL)
> +RELOC_TYPE (DOFFSET_IMM18BY2,  REL)
> +RELOC_TYPE (DOFFSET_IMM18BY4,  REL)

R_CKCORE_GOTOFF_IMM18 is missing, but it is also missing in elf.h.

> +RELOC_TYPE (GOT_IMM18BY4,  REL)
> +RELOC_TYPE (PLT_IMM18BY4,  REL)

R_CKCORE_PCREL_IMM7BY4 missing?

> +RELOC_TYPE (PCREL_IMM7BY4, REL)
> +RELOC_TYPE (TLS_LE32,  REL)
> +RELOC_TYPE (TLS_IE32,  REL)
> +RELOC_TYPE (TLS_GD32,  REL)
> +RELOC_TYPE (TLS_LDM32, REL)
> +RELOC_TYPE (TLS_LDO32, REL)
> +RELOC_TYPE (TLS_DTPMOD32,  EXEC|DYN)
> +RELOC_TYPE (TLS_DTPOFF32,  EXEC|DYN)
> +RELOC_TYPE (TLS_TPOFF32,   EXEC|DYN)

The TLS variants aren't yet listed in the CPU ABI doc, but are in
elf.h, so I assume they are OK.

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.

Cheers,

Mark

0.178 release next week

[Mark Wielaard]

Hi,

In another thread I said I would like to do a release end of this week
with the csky backend and the elfclassify tool integrated. But I didn't
make enough time for reviews, so that moves to next week. Sorry.

I should have enough time next week. But we will have to see if we can
polish the csky and elfclassify tool enough. If not, we'll still do a
release next week, just without those additions. The last 4 months saw
enough improvements to do a new release. And we'll do another in 3 or 4
months anyway, so if anything misses this release it will go into the
next.

Cheers,

Mark