OpenCores
no use no use 1/1 no use no use
Incompatible changes to GCC for OpenRISC
by jeremybennett on Aug 17, 2010
jeremybennett
Posts: 689
Joined: May 29, 2008
Last seen: Feb 9, 2012

There are some problems with the GCC compiler for OpenRISC and how it interacts with the rest of the tool chain (particularly GDB). I wish to fix this by making two significant changes to GCC. However, the first of these will result in new GCC generated binaries not being linkable with old GCC generated binaries.

In practice I believe this will not be a big issue, since we do not have a large body of pre-compiled library code out there. This post is for anyone affected to raise objections if they wish.

The two changes are:

  1. At present GCC prefixes all global symbols (functions and variables) in the compiled code with an underscore ('_'). Historically this was done to avoid namespace clashes. However with ELF output files it really is no longer needed. GDB struggles with mapping the high level names in the compiled code to the values in the object file symbol table, particularly with STABS debug info.

    Most modern compilers leave global names unchanged. I propose following this convention for OpenRISC. However it will mean that code compiled with the old compiler will not be linkable with code from the new compiler (since the naming convention for globals will be different). I don't believe this causes any problem in practice, since we do not have large bodies of pre-compiled library code out there.

  2. At present OpenRISC GCC generates STABS debugging info by default when -g is used. This is now quite an old, inconsistent and limited format. Most modern compilers generate DWARF2 debugging for -g. DWARF2 offers a richer debugging experience, and is the preferred format for GDB. It is what is generated if you use GCC with -ggdb.

    I propose making DWARF2 the default debugging format for OpenRISC GCC in the future. This should not cause compatibility problems. This is a longer term objective, since OpenRISC GCC does not always generate valid DWARF2 output at present.

It is my intention to implement the first proposal (remove underscore prefix for globals) for the release of GCC that will form part of the complete tool chain release at the end of September (see Toolchain development schedule announcement).

Moving to DWARF as the preferred debugging format will have to wait until we can get reliable DWARF2 output generated.

Any comments on these ideas welcome here or on IRC at freenode.net, channel #opencores.

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

RE: Incompatible changes to GCC for OpenRISC
by julius on Aug 17, 2010
julius
Posts: 323
Joined: Jul 1, 2008
Last seen: Feb 8, 2012
Both changes sound great Jeremy.

All libraries we work with now are recompiled regularly, there's no dependence on legacy libraries of any sort.

Nice one.
RE: Incompatible changes to GCC for OpenRISC
by jeremybennett on Aug 20, 2010
jeremybennett
Posts: 689
Joined: May 29, 2008
Last seen: Feb 9, 2012

The version of the tools in SVN has been updated to work without leading underscore being generated for global variables by GCC. Feedback welcome. A nasty bug in newlib startup has been fixed at the same time.

Regression failures with binutils, GCC and newlib are unchanged. Regression failures on GDB 7.1 have been significantly reduced (down to 441, from 3000+ in GDB 6.8).

Feedback welcome.

Jeremy

RE: Incompatible changes to GCC for OpenRISC
by jeremybennett on Aug 25, 2010
jeremybennett
Posts: 689
Joined: May 29, 2008
Last seen: Feb 9, 2012

The version of GCC in SVN has now been updated to generated DWARF2 output by default. This should eventually improve the GDB debugging experience, although it has temporarily made things a little worse.

GCC regression is marginally improved (one unexpected success is now an expected failure).

Feedback welcome as always.

Jeremy

no use no use 1/1 no use no use
© copyright 1999-2012 OpenCores.org, equivalent to ORSoC AB, all rights reserved. OpenCores®, registered trademark.