Discussion:
dietlibc cvs unstable
Felix von Leitner
2014-04-04 10:50:38 UTC
Permalink
The current dietlibc cvs is currently unstable because I recently
changed a few major things.

My main development platform is AMD64, so that should still work fine
for now.

The main change is: if dietfeatures.h contains WANT_TLS, errno is a now
thread-local variable. The syscall wrappers for all the platforms need
to be changed for this.

The other change is that I added a C11 threading library. C11 threading
is only a small subset of pthread, and I'm not much of a threading
expert, so the implementation might still be wrong. However, the new
threading code exclusively uses Linux 2.6+ primitives and should thus
scale much better than the pthread implementation we have.

I also tried to make dietlibc compile with clang, but that is an uphill
battle and right now does not work. I think we may be out of luck
unless we tell clang to use GNU as instead of the built-in assembler
which does not understand the macro functionality of GNU as that we use.

Help in any of these areas is greatly appreciated!

Felix
Lorenzo
2014-04-05 13:27:42 UTC
Permalink
Post by Felix von Leitner
The current dietlibc cvs is currently unstable because I recently
changed a few major things.
My main development platform is AMD64, so that should still work fine
for now.
The main change is: if dietfeatures.h contains WANT_TLS, errno is a now
thread-local variable. The syscall wrappers for all the platforms need
to be changed for this.
The other change is that I added a C11 threading library. C11 threading
is only a small subset of pthread, and I'm not much of a threading
expert, so the implementation might still be wrong. However, the new
threading code exclusively uses Linux 2.6+ primitives and should thus
scale much better than the pthread implementation we have.
I also tried to make dietlibc compile with clang, but that is an uphill
battle and right now does not work. I think we may be out of luck
unless we tell clang to use GNU as instead of the built-in assembler
which does not understand the macro functionality of GNU as that we use.
Help in any of these areas is greatly appreciated!
Felix
Tnx for the warning, for c11 and for clang!
thr_create.c: "stack = mmap(...); if(!stack)" - mmap doesn't return NULL
on failure.
Lorenzo
2014-04-05 13:59:17 UTC
Permalink
Post by Felix von Leitner
The current dietlibc cvs is currently unstable because I recently
changed a few major things.
My main development platform is AMD64, so that should still work fine
for now.
The main change is: if dietfeatures.h contains WANT_TLS, errno is a now
thread-local variable. The syscall wrappers for all the platforms need
to be changed for this.
The other change is that I added a C11 threading library. C11 threading
is only a small subset of pthread, and I'm not much of a threading
expert, so the implementation might still be wrong. However, the new
threading code exclusively uses Linux 2.6+ primitives and should thus
scale much better than the pthread implementation we have.
I also tried to make dietlibc compile with clang, but that is an uphill
battle and right now does not work. I think we may be out of luck
unless we tell clang to use GNU as instead of the built-in assembler
which does not understand the macro functionality of GNU as that we use.
Help in any of these areas is greatly appreciated!
Felix
I don't know futexes & friends enough to be useful, I'm not a threading
expert and I was lucky enough that my class taught us IJVM instead of
assembly :)


More seriously, these are all the other mmap() that look suspicious to me:

libdl/_dl_alloc.c => "tmp = mmap()" ???
libdl/_dl_load.c => d = do_map_in() unchecked
libdl/_dl_load.c line 139, unchecked mmap?
libdl/_dl_main.c mmap unchecked ??? (line 872)

I've never ever even peeked at libdl, so I have no idea if they are
actually bugs or just look bogus; all the other mmap() I could find were
checked correctly.
Enrico Scholz
2014-04-05 16:10:37 UTC
Permalink
[Maillist seems to have a broken filter which rejects all mails and
points to http://www.fefe.de/barf/contenttype.html. I am trying to
send the same message with telnet now...]
Post by Felix von Leitner
The main change is: if dietfeatures.h contains WANT_TLS, errno is a
now thread-local variable. The syscall wrappers for all the platforms
need to be changed for this.
Hi fefe,

I implemented basic TLS support (this means, non-tls programs build and
run with new code) for ARM. You can find the changes at the top of the
'rebase' Branch at

https://github.com/ensc/dietlibc/commits/rebase

But they are not applicable as-is because your codebase misses a lot of
ARM enhancements and fixes.



Enrico

Enrico Scholz
2014-04-17 00:17:57 UTC
Permalink
Post by Enrico Scholz
[Maillist seems to have a broken filter which rejects all mails and
points to http://www.fefe.de/barf/contenttype.html. I am trying to
send the same message with telnet now...]
Unfortunately, this is still the case. Felix, you should really fix
your stuff... Not everybody has the patience to sent manually crafted
mails with good old telnet.
Post by Enrico Scholz
Post by Felix von Leitner
The main change is: if dietfeatures.h contains WANT_TLS, errno is a
now thread-local variable. The syscall wrappers for all the platforms
need to be changed for this.
Hi fefe,
I implemented basic TLS support (this means, non-tls programs build and
run with new code) for ARM....
https://github.com/ensc/dietlibc/commits/rebase
contains now fixes for ppc (not ppc64 yet) and various other enhancements
so that it passes the testsuite.

See master branch for changes since last posting

https://github.com/ensc/dietlibc/commits/master


Enrico
Frank Bergmann
2014-04-17 07:35:12 UTC
Permalink
Hi.
Post by Enrico Scholz
Post by Enrico Scholz
[Maillist seems to have a broken filter which rejects all mails and
points to http://www.fefe.de/barf/contenttype.html. I am trying to
send the same message with telnet now...]
Unfortunately, this is still the case. Felix, you should really fix
your stuff... Not everybody has the patience to sent manually crafted
mails with good old telnet.
You don't need telnet if your MUA is properly configured.
IMHO all *text only* mailing lists should reject HTML emails and should
only accept plain text.
Postings on this list always have the same structure and layout and are
easy to read on every OS and MUA.

Just my 2 cents.

Frank
Enrico Scholz
2014-04-17 10:12:14 UTC
Permalink
Post by Frank Bergmann
Post by Enrico Scholz
Post by Enrico Scholz
[Maillist seems to have a broken filter which rejects all mails and
points to http://www.fefe.de/barf/contenttype.html. I am trying to
send the same message with telnet now...]
Unfortunately, this is still the case. Felix, you should really fix
your stuff... Not everybody has the patience to sent manually crafted
mails with good old telnet.
You don't need telnet if your MUA is properly configured.
my MUA is properly configured and sends mail as text/plain. See

https://www.cvg.de/people/ensc/dietlibc-bounce.txt

for a sample of the rejected mail with full headers.



Enrico
.
Frank Bergmann
2014-04-17 11:07:54 UTC
Permalink
Post by Enrico Scholz
my MUA is properly configured and sends mail as text/plain. See
https://www.cvg.de/people/ensc/dietlibc-bounce.txt
for a sample of the rejected mail with full headers.
1:0 for you
Fefe's error message does not match your mail.

One question is left: Did you post exactly the same message with the
complete header like it was rejected?

As long as Fefe doesn't resolve it we can only guess what's the cause:
- too many equal signs in "DKIM-Signature"
- too many minus signs on "X-Spam-Level"

Frank
Enrico Scholz
2014-04-17 11:27:55 UTC
Permalink
Post by Frank Bergmann
Post by Enrico Scholz
my MUA is properly configured and sends mail as text/plain. See
https://www.cvg.de/people/ensc/dietlibc-bounce.txt
for a sample of the rejected mail with full headers.
1:0 for you
Fefe's error message does not match your mail.
One question is left: Did you post exactly the same message with the
complete header like it was rejected?
No; I removed all the non-mandatory headers (like DKIM-Signature or the
MIME headers).

But I have a suspicion... let's see whether this mail gets through when
I add an umlaut: ΓΌ

When you see this, it means the filter requires a '; charset=...' option
for 'Content-Type:'. I am not aware of any standard which makes this
optional attribute mandatory.



Enrico
Felix von Leitner
2014-04-19 13:15:33 UTC
Permalink
Post by Frank Bergmann
Post by Enrico Scholz
my MUA is properly configured and sends mail as text/plain. See
https://www.cvg.de/people/ensc/dietlibc-bounce.txt
for a sample of the rejected mail with full headers.
1:0 for you
Fefe's error message does not match your mail.
One question is left: Did you post exactly the same message with the
complete header like it was rejected?
- too many equal signs in "DKIM-Signature"
- too many minus signs on "X-Spam-Level"
I think I fixed it.
The parser was wrong in the case where there was no charset declaration
behind the mime type.

Do be honest, I'm flabberghasted this has not manifested before.
The barf binary was von 2002.

Felix

Felix von Leitner
2014-04-17 11:35:18 UTC
Permalink
Post by Enrico Scholz
Post by Enrico Scholz
[Maillist seems to have a broken filter which rejects all mails and
points to http://www.fefe.de/barf/contenttype.html. I am trying to
send the same message with telnet now...]
Unfortunately, this is still the case. Felix, you should really fix
your stuff... Not everybody has the patience to sent manually crafted
mails with good old telnet.
I think I fixed it.
The barf binary is from 2002, how the hell is this only coming to light
now?!

Felix
Loading...