Re: [[RESEND & PING]PATCH V3 1/1] Add backend support for C-SKY
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
Re: 0.17(8 -> 7) release next week
On Sat, 2019-07-13 at 00:36 +0200, Mark Wielaard wrote: > 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. Just for the record, the subject should of course have been 0.177. Cheers, Mark
[Bug tools/24809] New: eu-unstrip to drop SECTION symbols if section .note.gnu.gold-version present
https://sourceware.org/bugzilla/show_bug.cgi?id=24809
Bug ID: 24809
Summary: eu-unstrip to drop SECTION symbols if section
.note.gnu.gold-version present
Product: elfutils
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: tools
Assignee: unassigned at sourceware dot org
Reporter: vries at gcc dot gnu.org
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Consider a hello world with debug info, linked using gold:
...
$ gcc hello.c -g -fuse-ld=gold -o hello
...
Now say we strip using objcopy, and then unstrip:
...
$ objcopy --only-keep-debug hello hello.debug
$ objcopy --strip-debug hello hello.stripped
$ eu-unstrip hello.stripped hello.debug -o hello.unstripped
...
Interestingly, the unstripped exec is larger than the original:
...
$ ls -la
-rwxr-xr-x 1 vries users 14104 15 jul 12:34 hello
-rwxr-xr-x 1 vries users 11528 15 jul 12:34 hello.debug
-rwxr-xr-x 1 vries users 8760 15 jul 12:34 hello.stripped
-rwxr-xr-x 1 vries users 14896 15 jul 12:34 hello.unstripped
...
Comparing section sizes, we get:
...
$ readelf -S -W hello | grep ']'| sed 's/\[ /[/' | egrep -v 'NULL|Name' | awk
'{print $2, $6}' > SIZE.1
$ readelf -S -W hello.unstripped | grep ']'| sed 's/\[ /[/' | egrep -v
'NULL|Name' | awk '{print $2, $6}' > SIZE.2
$ diff -u SIZE.1 SIZE.2
--- SIZE.1 2019-07-15 12:43:14.495608629 +0200
+++ SIZE.2 2019-07-15 12:43:07.743655249 +0200
@@ -35,6 +35,6 @@
.debug_ranges 80
.debug_loc 00013e
.note.gnu.gold-version 1c
-.symtab 0003c0
-.strtab 000213
+.symtab 000720
+.strtab 0001cf
.shstrtab 000190
...
That is, the .strtab section is slightly smaller, but the .symtab section
significantly larger.
The difference is because of the SECTION symbols, which ld normally adds, but
gold doesn't. However, objcopy adds them nevertheless:
...
$ readelf -s hello | grep -c SECTION
0
$ readelf -s hello.debug | grep -c SECTION
37
$ readelf -s hello.stripped | grep -c SECTION
30
$ readelf -s hello.unstripped | grep -c SECTION
37
...
It would be good if eu-unstrip could recognize the fact that the exec was
produced using gold (there seems to be a section .note.gnu.gold-version) and
drop those symbols (and likewise, objcopy should probably do the same).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug tools/24809] eu-unstrip to drop SECTION symbols if section .note.gnu.gold-version present
https://sourceware.org/bugzilla/show_bug.cgi?id=24809 --- Comment #1 from Mark Wielaard --- I can replicate this if I use objcopy to produce the hello.debug and hello.stripped binaries. But why don't you just use eu-strip? Doing: $ eu-strip -f hello.debug -o hello.stripped hello $ eu-unstrip hello.stripped hello.debug -o hello.unstripped Produces: $ ls -la -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:50 hello -rw-rw-r--. 1 mark mark92 Jul 15 14:50 hello.c -rwxrwxr-x. 1 mark mark 6840 Jul 15 14:52 hello.debug -rwxrwxr-x. 1 mark mark 6488 Jul 15 14:52 hello.stripped -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:52 hello.unstripped $ readelf -s hello.debug | grep -c SECTION 0 $ readelf -s hello.stripped | grep -c SECTION 0 $ readelf -s hello.unstripped | grep -c SECTION 0 Which seems much more reasonable than what objcopy does. I am not sure eu-unstrip should remove extra stuff objcopy adds. It seems that if the user created these bigger than necessary .debug and .stripped files, then they wanted that for some reason. It seems unwise to second guess the user. If there is a bug, then I think it is simply a bug in objcopy, which can be prevented by using eu-strip instead. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/24809] objcopy to not add SECTION symbols if section .note.gnu.gold-version present
https://sourceware.org/bugzilla/show_bug.cgi?id=24809 Tom de Vries changed: What|Removed |Added Component|tools |binutils Version|unspecified |2.33 (HEAD) Product|elfutils|binutils Summary|eu-unstrip to drop SECTION |objcopy to not add SECTION |symbols if section |symbols if section |.note.gnu.gold-version |.note.gnu.gold-version |present |present --- Comment #2 from Tom de Vries --- (In reply to Mark Wielaard from comment #1) > I can replicate this if I use objcopy to produce the hello.debug and > hello.stripped binaries. But why don't you just use eu-strip? > I think the idea here is to have the tools from the two "products" to play nice together. > Doing: > $ eu-strip -f hello.debug -o hello.stripped hello > $ eu-unstrip hello.stripped hello.debug -o hello.unstripped > > Produces: > $ ls -la > -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:50 hello > -rw-rw-r--. 1 mark mark92 Jul 15 14:50 hello.c > -rwxrwxr-x. 1 mark mark 6840 Jul 15 14:52 hello.debug > -rwxrwxr-x. 1 mark mark 6488 Jul 15 14:52 hello.stripped > -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:52 hello.unstripped > > $ readelf -s hello.debug | grep -c SECTION > 0 > $ readelf -s hello.stripped | grep -c SECTION > 0 > $ readelf -s hello.unstripped | grep -c SECTION > 0 > > Which seems much more reasonable than what objcopy does. > Right, I noticed that. > I am not sure eu-unstrip should remove extra stuff objcopy adds. It seems > that if the user created these bigger than necessary .debug and .stripped > files, then they wanted that for some reason. It seems unwise to second > guess the user. > > If there is a bug, then I think it is simply a bug in objcopy, which can be > prevented by using eu-strip instead. OK, changing product to binutils. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [[RESEND & PING]PATCH V3 1/1] Add backend support for C-SKY
On Mon, 2019-07-15 at 16:55 +0800, Mao Han wrote:
> 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.
Sorry about taking so long to go over these patches.
Thanks for answering the questions. I do have the older emails and I do
see I did ask some of these earlier and you already had answered them.
Most of my confusion seems to come back to this RCE/MCORE vs CSKY
thing.
> 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.
So the zeroptr binary looks correct now.
But the core.zeroptr is probably generated by an older linux kernel and
still is EM_RCE. This confusion is a bit confusing since I makes it
really hard to check the details (register numbering, etc.) are really
correct. I can tweak the code a bit to accept EM_RCE as EM_CSKY but
then the PRSTATUS core note doesn't look correct. I am not sure that is
because the register set as dumped by the kernel is bogus or because
the prstatus_regs definition in csky_corenote.c is incorrect.
> > > 5. run-reverse-sections-self.sh
> > > elfcopy --reverse-offs dose not work properly on C-SKY object
> > > file,
> > > [...]
> This case can pass with the newest elfutils. I believe it is fixed
> with commit d08c68.
Cool.
> > 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.
OK. It is fine as is then. Just wanted to make sure it was as intended.
> > 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.
OK. If you can add that tweak to src/readelf.c and add an
check_object_attribute hook that handles the above attributes that
would be good.
Ideally you also add a testcase for tests/readelf-A.sh
Some of those tests cheat and create the attributes by hand.
But it would be nice if you could generate a small .o file with the
latest toolchain to be used as testcase in some other tests.
Look for example at tests/run-addrcfi.sh. Which has this somewhat
"standard" test object file:
# = bar.c =
#
# static int b1 = 1;
# int b2 = 1;
#
# static int
# foo (int a)
# {
# return a + b2;
# }
#
# int bar (int
