This is the mail archive of the ecos-patches@sourceware.org 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: POSIX threads early startup C++ exceptions


Øyvind Harboe wrote:
On 8/11/06, Jonathan Larmour <jifl@jifvik.org> wrote:
By implication from this code, you're trying to get C++ code to operate
even before the kernel is initialised, hence the hoops with self==NULL.
It's an invitation to problems. I'm extremely hesitant about trying to
claim that C++ code will work at such an early stage of initialisation.

It's hard to argue against a fear about something that you believe might exist.

By going to the effort of getting something working, it implies it works and we want it to work. Before the kernel is even initialised, nevermind started, that's a very difficult position to maintain.


Even CYG_INIT_IO is after CYG_INIT_KERNEL, so I'm not clear what
initialisation you are trying to support. C++ exceptions in the HAL? I'd
surely have thought not, but if not but it's HAL code, why not just build
with -fno-exceptions.

I'm decompressing an FPGA image while programming an FPGA. There are *many* things that can go wrong and this code is *greatly* simplified by having exceptions.

This probably is just going to come down to a difference of opinion, but in my view exceptions are meant to be exactly that - things that are out of the ordinary and should not happen in the normal course of events. HAL initialisation should either work or fail. Exceptions should not be used as intra-program communication.


You can still use setjmp/longjmp. Although I'm aware that doesn't help if you are relying on automatic calling of C++ destructors for stack objects.

Decompressing the FPGA must happen before CYG_INIT_IO since there is a
UART in the FPGA.

Okay.


These changes also add bloat to support something that almost no-one will
want to do, and are at best hardware specific.

Bloat? Isn't this so little as to nearly be a matter of subjective opinion? Doesn't POSIX threads get used in system that have a little more oomph so percentage wise this should be miniscule?

It's the thin end of the wedge. With pretty much the sole exceptions of the BSD net stack and SNMP stack, eCos has always endeavoured to be lightweight, including in the POSIX layer. POSIX adds a fair bit of code (ROM space), but does not need to add much data (RAM space). Your change adds over half a K of data to every POSIX library user. All to support one implementation of one particularly early running driver, solely at initialisation time, and not thereafter.


I'm sure this patch is entirely right for your code design and implementation preferences, but I don't see it being generally applicable, and only see it adding unnecessary space for virtually everyone. In this case, other users may not be using POSIX threads because they want to, but only because they are required to by the libstdc++ implementation. You can't assume they have that oomph.

eCos is open source so you have the freedom of making changes like this. It doesn't mean that every change needs to be contributed back for all to use, particularly if it is highly specialised.

Anyway, I've said my bit. I suspect unfortunately we may have to agree to disagree.

Jifl
--
--["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]