This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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).



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 :).


eCosCentric    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]