(Some) C++ support?

[Paul Sokolovsky]

Hello,

What about some C++ support, after all? To answer question (or
outright negative statement) why that would be needed: C++ is
multi-paradigm language, and there're different uses, including -
surprisingly - right and useful. 2 typical examples of usages which may
be well target area of dietlibc too:

1. Metaprogramming - using compile-time compositional facilities (OO
and functional) to achieve high run-time efficiency, beyond C
capabilities, and within compromising high-level abstactions of target
domain.

2. Using "syntactic sugar" runtime object orientation plus things like
polymorphism.

Note that in both cases I don't talk about libstdc++ - it's optional
for C++ programming.

Giving specific example of case 2, I tried to compile Squirrel
scripting language (http://squirrel-lang.org/) with dietlibc. I had to
unbreak "diet" tool to not goto too hasty to donttouch label on seeing
something but "*cc" as a compiler, and in result I got link errors only
of following classes (each repeated multiple times of course):

sqapi.cpp:(.text._ZN13SQCollectableD0Ev[_ZN13SQCollectableD5Ev]+0x1f): undefined reference to `operator delete(void*)'
squirrel/sqapi.o:(.rodata._ZTV13SQCollectable[vtable for SQCollectable]+0x10): undefined reference to `__cxa_pure_virtual'

operator delete(void*p) would be just { free(p); }
and __cxa_pure_virtual() - { abort(); }


That's exactly what's I'd call "some C++ support" ;-). I'm not sure
how many apps would benefit from it, but at least one above will, and
it's truly good target for dietlibc (Squirrel is both tiny (~200Kb
executable and feature-rich)). More importantly, it will allow folks to
write C++ apps to be compiled with dietlibc, in really good C+
style ;-).



Just as extra note, before I patched "diet", the source was compiled
against glibc headers, and was plagued by _FORTIFY_SOURCE curse. After
I disabled it (-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0), it turned out
that when linking with static -lstdc++, then -lstdc++ contains code
compiled with _FORTIFY_SOURCE, so it's of all those *_chk symbols. So,
I even wanted to ask about an idea to provide compatibility lib, which
would just remap glibc's *_chk symbols into original function calls,
but it all was much better fixed my patching "diet" to not be afraid of
g++. And if aiming for "C++ stdlib" support, then using saner
(than glibc's libstdc++) solutions like STLPort seems like better idea.

[Felix von Leitner]

Post by Paul Sokolovsky
What about some C++ support, after all?

I have no fundamental problem with that.

Unfortunately, there are a few obstacles,

First of all, to even link a C++ program with dietlibc, you cannot use
libstdc++ (iostreams, STL) because those depend on undocumented internal
features of glibc that we do not support. We would have to provide our
own STL implementation.

And if you have a program that does not use STL, dietlibc still needs to
supply some functions for parsing ELF debug symbols because that's how
C++ exception handling works on Linux. The compiler generates code
using those functions, and we don't have them.

Post by Paul Sokolovsky
sqapi.cpp:(.text._ZN13SQCollectableD0Ev[_ZN13SQCollectableD5Ev]+0x1f): undefined reference to `operator delete(void*)'
squirrel/sqapi.o:(.rodata._ZTV13SQCollectable[vtable for SQCollectable]+0x10): undefined reference to `__cxa_pure_virtual'
operator delete(void*p) would be just { free(p); }
and __cxa_pure_virtual() - { abort(); }

LOL

Post by Paul Sokolovsky
Just as extra note, before I patched "diet", the source was compiled
against glibc headers, and was plagued by _FORTIFY_SOURCE curse. After
I disabled it (-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0), it turned out
that when linking with static -lstdc++, then -lstdc++ contains code
compiled with _FORTIFY_SOURCE, so it's of all those *_chk symbols. So,
I even wanted to ask about an idea to provide compatibility lib, which
would just remap glibc's *_chk symbols into original function calls,
but it all was much better fixed my patching "diet" to not be afraid of
g++. And if aiming for "C++ stdlib" support, then using saner
(than glibc's libstdc++) solutions like STLPort seems like better idea.

I think a better approach than STLport would be to look at the libc++
from clang/llvm as a starting point. If we support C++, we might as
well go all in and use C++11.

Felix

[Paul Sokolovsky]

Hello,

On Wed, 14 Aug 2013 22:19:49 +0200

Post by Felix von Leitner

Post by Paul Sokolovsky
What about some C++ support, after all?

I have no fundamental problem with that.
Unfortunately, there are a few obstacles,
First of all, to even link a C++ program with dietlibc, you cannot use
libstdc++ (iostreams, STL) because those depend on undocumented
internal features of glibc that we do not support. We would have to
provide our own STL implementation.

Or rather, use existing unbloated STL implementation, as discussed
below.

Post by Felix von Leitner
And if you have a program that does not use STL, dietlibc still needs
to supply some functions for parsing ELF debug symbols because that's
how C++ exception handling works on Linux. The compiler generates
code using those functions, and we don't have them.

Exceptions?! No, supporting those in dietlibc didn't even come to my
mind. Before even using them, there should be decent implementation of
them in mainstream compilers, not typical setjmp/longjmp crap how it
was few years ago, so now everyone just dreads to use them. Exceptions
and RTTI of course have their uses too, but I don't remember seeing not
too big C++ app lately which wouldn't use -fno-exceptions -fno-rtti.

Post by Felix von Leitner

Post by Paul Sokolovsky
undefined reference to `operator delete(void*)'
squirrel/sqapi.o:(.rodata._ZTV13SQCollectable[vtable for
SQCollectable]+0x10): undefined reference to `__cxa_pure_virtual'
operator delete(void*p) would be just { free(p); }
and __cxa_pure_virtual() - { abort(); }

LOL

And yet I mean just that ;-). It is helpful already (Squirrel builds
and kinda runs, unfortunately there's no testsuite to do regression
testing), and can be basis for any future effort (by whoever needs
more).

Of course, it would be too childish to call that -lstdc++ in dietlibc,
but it could very well go into something like -lc++supp IMHO.

Post by Felix von Leitner

Post by Paul Sokolovsky
Just as extra note, before I patched "diet", the source was compiled
against glibc headers, and was plagued by _FORTIFY_SOURCE curse.
After I disabled it (-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0), it
turned out that when linking with static -lstdc++, then -lstdc++
contains code compiled with _FORTIFY_SOURCE, so it's of all those
*_chk symbols. So, I even wanted to ask about an idea to provide
compatibility lib, which would just remap glibc's *_chk symbols
into original function calls, but it all was much better fixed my
patching "diet" to not be afraid of g++. And if aiming for "C++
stdlib" support, then using saner (than glibc's libstdc++)
solutions like STLPort seems like better idea.

I think a better approach than STLport would be to look at the libc++
from clang/llvm as a starting point. If we support C++, we might as
well go all in and use C++11.

Well, my mentioning of STL support was based on the idea that it still
would be useful for not too big apps. For example, a package manager
could easily use maps, lists and vectors. And a package manager would
be natural target to be compiled against dietlibc. Mentioning STLPort
was in turn based on knowing that folks use it on AVR MCU:
https://github.com/vancegroup/stlport-avr . Something usable on AVR
should be good enough to use with dietlibc, the opposite may not be
true.

All in all, I just wanted to report that it takes fairly minor changes
to build no-nonsense example of unbloated C++ code OOB with dietlibc,
and leave some ideas in the ML archive for whoever may look for that
(my quick look at gmane archive didn't bring any recent threads).

I'll try to prepare patches then.

Post by Felix von Leitner
Felix

[Felix von Leitner]

Post by Paul Sokolovsky

Post by Felix von Leitner
And if you have a program that does not use STL, dietlibc still needs
to supply some functions for parsing ELF debug symbols because that's
how C++ exception handling works on Linux. The compiler generates
code using those functions, and we don't have them.

Exceptions?! No, supporting those in dietlibc didn't even come to my
mind.

Uh, if you use any kind of STL, you need exception support.
All the containers in the STL can throw.
Also, operator new throws.

Post by Paul Sokolovsky
Before even using them, there should be decent implementation of
them in mainstream compilers, not typical setjmp/longjmp crap how it
was few years ago, so now everyone just dreads to use them. Exceptions
and RTTI of course have their uses too, but I don't remember seeing not
too big C++ app lately which wouldn't use -fno-exceptions -fno-rtti.

Exceptions have not been using setjmp/longjmp for 10+ years on Linux, I
would say around 15 years even.

Which is exactly the problem now for us, because setjmp/longjmp we
support in dietlibc :-)

Felix