This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: gcc-3.2 for SPARC port broken?
Jiri Gaisler wrote:
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.
Sure. But this probably means _no_ constructor priority is working - fileio
is just what shows that fact up first.
gcc-2.95 somehow
generates the correct constructor order, but gcc-3.2 does not.
Comparing a sparc-elf-objdump -h of the relevant .o files (e.g.
kernel_thread.o etc.) between objects generated by the two GCCs should help
point to what is wrong.
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.
The HAL should be able to do:
requires { !is_substr(CYGPKG_INFRA_LDFLAGS_ADD, "-Wl,--fatal-warnings") }
although that might still result in a conflict to be resolved, but at least
the user should just click okay and that's it done, so less error prone.
Sticking with gcc 2.95 isn't a long term solution though. And unless a bug
report is submitted to the gcc project, there's no guarantee this will be
fixed, so it's worth investigating this further.
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?
Not me, but code review may also help show that up so it's worth posting
them here more generally (with that caveat).
Thanks,
Jifl
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
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine