Question:
How do I submit code for supporting a new processor (Tilera TILE-Gx)? I've gotten it all working.
Thanks.
jeff kenton, Tilera Corporation
Hi -
On Thu, Aug 09, 2012 at 09:14:32AM -0400, Jeff Kenton wrote:
[...] How do I submit code for supporting a new processor (Tilera TILE-Gx)? I've gotten it all working.
Please send patches to this same mailing list, see also: http://git.fedorahosted.org/cgit/elfutils.git/tree/CONTRIBUTING
- FChE
Hi Jeff,
On Thu, 2012-08-09 at 09:14 -0400, Jeff Kenton wrote:
How do I submit code for supporting a new processor (Tilera TILE-Gx)? I've gotten it all working.
Please add your patches to a local git tree/branch. Then you can use git format-patch to create patches for review or use git send-email to send them to this list directly so they can be reviewed.
For some (legal) formalities please read the CONTRIBUTING file: http://git.fedorahosted.org/cgit/elfutils.git/tree/CONTRIBUTING
If there are any ELF or DWARF extensions for the architecture please also point to the processor supplement documentation. Having some object files with those extensions present would be helpful for testing on other architectures (we could add them to the testsuite).
Thanks,
Mark
On 08/09/2012 10:17 AM, Mark Wielaard wrote:
Hi Jeff,
On Thu, 2012-08-09 at 09:14 -0400, Jeff Kenton wrote:
How do I submit code for supporting a new processor (Tilera TILE-Gx)? I've gotten it all working.
Please add your patches to a local git tree/branch. Then you can use git format-patch to create patches for review or use git send-email to send them to this list directly so they can be reviewed.
Follow on questions:
1. I had done my initial development from the elfutils-0.154 tarball, not from a git tree. From the tarball all I had to do was "configure" and "make". The git tree is missing a configure file and various Makefile.in's (and a few other things). I can copy the missing files into the tree and continue, but I'm sure that's not the best way. What's the best way?
2. When building, the compiler complains about readelf.c -- it's missing one line in the table "known[]" inside print_ops(), for the value of DW_OP_GNU_parameter_ref, which is referenced in a case statement and a printf() right before the "default" at about line 4420. It's trivial to add this as the last line in the known[] table.
3. elflint.c, at line 954, generates an error:
section [36] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x20c28 does not match .got.plt section address 0x20cb8
for many of the *.so files it checks. This is because the *.so intentionally points to ".got" rather than ".got.plt". Our gcc guy doesn't believe this is an error.
Thanks.
--jeff kenton
On Thu, 2012-08-16 at 10:57 -0400, Jeff Kenton wrote:
- I had done my initial development from the elfutils-0.154 tarball,
not from a git tree. From the tarball all I had to do was "configure" and "make". The git tree is missing a configure file and various Makefile.in's (and a few other things). I can copy the missing files into the tree and continue, but I'm sure that's not the best way. What's the best way?
When working with a git checkout first run autoreconf -f -v -i to generate the auto* files then configure using --enable-maintainer-mode
- When building, the compiler complains about readelf.c -- it's missing
one line in the table "known[]" inside print_ops(), for the value of DW_OP_GNU_parameter_ref, which is referenced in a case statement and a printf() right before the "default" at about line 4420. It's trivial to add this as the last line in the known[] table.
Ah, that fallout of my dwarfstrings branch not having been completely merged yet. Sorry. The idea is to get rid of these hard coded tables. Hopefully today or tomorrow it gets all merged. But till that time just adding it into the table manually should print things out correctly again.
elflint.c, at line 954, generates an error:
section [36] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x20c28
does not match .got.plt section address 0x20cb8
for many of the *.so files it checks. This is because the *.so intentionally points to ".got" rather than ".got.plt". Our gcc guy doesn't believe this is an error.
I would have to look that up.
Cheers,
Mark
On 08/16/2012 11:09 AM, Mark Wielaard wrote:
On Thu, 2012-08-16 at 10:57 -0400, Jeff Kenton wrote:
- I had done my initial development from the elfutils-0.154 tarball,
not from a git tree. From the tarball all I had to do was "configure" and "make". The git tree is missing a configure file and various Makefile.in's (and a few other things). I can copy the missing files into the tree and continue, but I'm sure that's not the best way. What's the best way?
When working with a git checkout first run autoreconf -f -v -i to generate the auto* files then configure using --enable-maintainer-mode
Perfect -- thanks.
--jeff
On Thu, 2012-08-16 at 17:09 +0200, Mark Wielaard wrote:
On Thu, 2012-08-16 at 10:57 -0400, Jeff Kenton wrote:
elflint.c, at line 954, generates an error:
section [36] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x20c28
does not match .got.plt section address 0x20cb8
for many of the *.so files it checks. This is because the *.so intentionally points to ".got" rather than ".got.plt". Our gcc guy doesn't believe this is an error.
I would have to look that up.
This sounds a bit like an old binutils gold linker issue: http://sourceware.org/bugzilla/show_bug.cgi?id=10450#c1
What compiler and linker versions are you using?
Could you send a small .so binary testcase compiled from some trivial source (please quote the source and build commands), then we can inspect the binary directly (and when your port is in then we could cross check on other arches).
Thanks,
Mark
On 08/16/2012 05:23 PM, Mark Wielaard wrote:
On Thu, 2012-08-16 at 17:09 +0200, Mark Wielaard wrote:
On Thu, 2012-08-16 at 10:57 -0400, Jeff Kenton wrote:
elflint.c, at line 954, generates an error:
section [36] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x20c28
does not match .got.plt section address 0x20cb8
for many of the *.so files it checks. This is because the *.so intentionally points to ".got" rather than ".got.plt". Our gcc guy doesn't believe this is an error.
I would have to look that up.
This sounds a bit like an old binutils gold linker issue: http://sourceware.org/bugzilla/show_bug.cgi?id=10450#c1
What compiler and linker versions are you using?
Could you send a small .so binary testcase compiled from some trivial source (please quote the source and build commands), then we can inspect the binary directly (and when your port is in then we could cross check on other arches).
Thanks,
Mark
Now that the Tilera port is in I thought I'd re-open this question:
- We are using our own port of gcc 4.4.6 for the Tilera processor (it's a custom processor, so doesn't match anything else). - We are using binutils ld 2.21, not the Gold Linker. - We have deliberately created the entry that elflint is complaining about, pointing to ".got" rather than ".got.plt". Our gcc guy has reasons for this (I can get the details) and he claims it's legal. I don't have a trivial .so binary for you -- the smallest I'm building is about 60K.
--jeff
elfutils-devel@lists.fedorahosted.org