Re: gcc-3.2 for SPARC port broken?

[Jiri Gaisler <jiri at gaisler dot com>]

I have investigated a bit further, and the problem comes when
additional packages such as fileio are enabled. In such cases,
the constructors from the other packages are run before the
kernel constructors, resulting in crashes because certain
kernel variables are not initialised. gcc-2.95 somehow
generates the correct constructor order, but gcc-3.2 does not.

As a remedy, I have switched bac to using gcc-2.95. However,
in ecos-2.0, the infrastructure uses the ld flag --fatal-warnings
which is not understod by the older linker and compilation of
the tests fail. Upgrading to a new binutils generate a different
problem: when c++ applications are compiled, the linker suddently
starts complaning about that the link script does not have an
entry for section .ram_vectors. This even if the final binary
does not include such a section! I am therefore forced to stay
with the older linker version. The question is now: is there
a way to remove the --fatal-warnings flag from CYGPKG_INFRA_LDFLAGS_ADD
automatically, i.e. as soon as the sparc port is selected?
The flag is global, so I am not sure how the sparc port can
disable/redefine it. Having to do this manually every time
in ecos.ecc or through configtool is slow and will lead to
confusion when new users hit this problem.

One more thing: I have fixed a few subtle bugs in the LAN91C111
network driver, regarding the 32-bit data mode on big-endian
hosts and a wrong reset sequence. I believe I did not break
the 16-bit mode but I am not able to test this. Is there somebody
on the list who uses this driver and who would be willing to
test the patches before I submit them?

Jiri.

Jonathan Larmour wrote:
> Jiri Gaisler wrote:
>
> > I am trying to clean up the leon2/sparc port, and add support for the
> > upcoming leon3. I have noticed then when using gcc-3.2, the c++
> > contructors are not called in the right order and the apps crashes
> > due to various null pointers. This does not happen with gcc-2.95.x .
> >
> > Does somebody know a solution for this problem, or is the work-around
> > to stay with gcc-2.95.x ?
>
>
> Seems possible that something has changed about the way this is handled. 
> If you're still using a sparc-rtems triplet rather than sparc-elf, it 
> might have changed in some way that is RTEMS specific. You might also 
> want to objdump some .o files with prioritised constructors in to see if 
> they have the correct section names (e.g. .ctors.12345). Or it might 
> show they are in some other section. If it isn't obvious then a linker 
> map may show up how the constructors are getting in.
>
> Or of course it could be a bug :).
>
> Jifl

--
-------------------------------------------------------------------------
Gaisler Research, Första Långgatan 19 S-413 27 Göteborg +46-317758650
fax: +46-31421407 email: info@gaisler.com, home page: www.gaisler.com
-------------------------------------------------------------------------