-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Clang support for DCE #50
Open
teto
wants to merge
39
commits into
direct-code-execution:master
Choose a base branch
from
teto:test
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… a script to generate those
... manually with teh zsh script at the beginning. Ideally, it should be run by waf. Aliases are disabled for now while I confirm clang support for weak linking. avr-llvm/clang#9
... so that one can fix them lateR. Still have a problem when linking dce library
runner ['g++', '-Wl,--no-as-needed', '-pthread', '-nostdlib', '-fno-profile-arcs', '-Wl,--version-script=model/libc.version', '-Wl,-soname=libc.so.6', '-shared', 'model/libc.cc.84.o', 'model/libc-setup.cc.84.o', 'model/libc-global-variables.cc.84.o', '-o', '/home/teto/dce/build/lib/libc-ns3.so', '-Wl,-Bstatic', '-Wl,-Bdynamic']
to see libc symbols, important to get the -D : nm -D /lib/x86_64-linux-gnu/libc.so.6|less
…--undefined=symbol to the linker. objdump -d |grep NEEDED allows to see DT_NEEDED dependancies. interesting to see on libc-ns3 and libns3-dce.
If I could alias a C function to a C++ one (tested, looks ok)à, then that could be nice: Problem is how to get the mangled name ?
Indeed from std >= 99, the , ## __VA_ARGS__ stopped being supported by gcc. P99 (http://p99.gforge.inria.fr/p99-html/) supports a way to do that. Bottom line is for now you should include -I/path/to/p99 so that the code compiles. Instead of writing the prototypes by hand, it would be nice if one could use libclang/castxml to generate the libc-ns3.generated.h
because I had removed the 'extern "C"' directive but now the trick to remove the parameter name becomes useless as it forces C++ binding :/ Gess I have to use castxml :/
doc/source/Posix_Coverage.csv could be generated sysinfo/pthread_kill and sigaction look into the wrong includes ! sysinfo/dce-utsname.h est mauvais aussi (devrait etre dans sys/utsname.h sys/sysinfo.h) sys/wait.h le wait est pas bon non plus -nostdinc pour ne pas chercher dans les dossiers par défaut -nostdinc++ C_INCLUDE_PATH C++ (chrono/cmath) /usr/include/c++/5 /usr/include/x86_64-linux-gnu/c++/5 hashtable/auto_ptr /usr/include/c++/5/backward etrange, qques fichiers std,varargs.h /usr/lib/gcc/x86_64-linux-gnu/5/include OK /usr/local/include SERT A RIEN /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed celui ci peut etre un problems /usr/include/x86_64-linux-gnu /usr/include -I cflags va_list ap is not recognized extern int dce_vasprintf (__restrict__ char * *,__restrict__ char const *,?unknown? *); regression sur le basename pb avec tout ce qui est explicite
Many files added but they are generated. still need to fix the generation of headers doc/source/Posix_Coverage.csv could be generated declaration_matchers.py matchers.py find_all_declaration does_match_exist ? pthread_mutex_unlock not found ? agi manpages-posix-dev sysinfo/pthread_kill and sigaction look into the wrong includes ! sysinfo/dce-utsname.h est mauvais aussi (devrait etre dans sys/utsname.h sys/sysinfo.h) sys/wait.h le wait est pas bon non plus -nostdinc pour ne pas chercher dans les dossiers par défaut -nostdinc++ C_INCLUDE_PATH C++ (chrono/cmath) /usr/include/c++/5 /usr/include/x86_64-linux-gnu/c++/5 hashtable/auto_ptr /usr/include/c++/5/backward etrange, qques fichiers std,varargs.h /usr/lib/gcc/x86_64-linux-gnu/5/include OK /usr/local/include SERT A RIEN /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed celui ci peut etre un problems /usr/include/x86_64-linux-gnu /usr/include -I cflags va_list ap is not recognized extern int dce_vasprintf (__restrict__ char * *,__restrict__ char const *,?unknown? *);
While waiting to fix pygccxml, I include a file fixed by hand: model/libc.generated.tmp.c
-fno-exceptions -ferror-limit /home/teto/dce/model/libc-ns3.h|43|error: assigning to 'decltype(&atexit)' (aka 'int (*)(void (*)()) throw()') from incompatible type 'int (*)(void (*)())'| clang n'aime pas le "throw()" dans le decltype, must be added to declarations (and even implementation ?!) pygcxxxml scanner.py c la ou il lit le doc.
There are still pb with more detailed specifiers such as __attribute__(noreturn)
clang supports -ftest-coverage but not -fno-test-coverage ; I have to check this out.
since gcc and clang options differ. Also added __cxa_exit|finalize to Libc but tests still fail. libgcc is required at some point...
…w['extra'] in finddef.py; it works
Now trying to reenable some private functions of libc like __printf_chk. They can be parsed in <bits/stdio2.h> if you define some good macros. //#undef __USE_FORTIFY_LEVEL //#define __USE_FORTIFY_LEVEL 2 // //#include <bits/stdio2.h> //#undef __USE_FORTIFY_LEVEL
Some tests pass, others don't (fd-simple /stdio). I don't know yet how to debug those :/ My strategy is to first pass the tests with GCC, then with clang.
dce_exit was returning 256 as an exit value while the program returned 0. I thus modified the dce_exit but that might be a mistake. Some problems I encoutered were due to the tests not being run in tempdir, thus I sent a patch to ns3 to do just that and modified DceManagertest accordingly. snprintf doesn't seem to be exported yet and test-exec still fails, apparently due to some bad conversion from C string to C++ string (look for CopyArgs).
you can't forward an ellipsis: http://stackoverflow.com/questions/695982/passing-an-ellipsis-to-another-variadic-function Hence the solution is in finddef.py to look for ellipsis and convert the DCE prototypes accordingly so that it can accept va_list instead of ellipsis.
TODO: create an option to regen the cache also, even when writing is not enabled, it deletes the content of libc.generated.cc :/
Correctly forward call to the native function accepting va_list (assuming it's prefixed with "v"). First 4 tests pass
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR allows clang to compile DCE. Tests still fail though.
It adds a script "finddef.py" that relies on castxml and pygccxml to find the libc declaration from the function name.
$ finddef.py -a
will parse model/libc-ns3.h and generate the appropriate wrappers and headers in libc.generated.ccFor instance, in libc-ns3, you have DCE(srandom) and it will be converted into
This allows to get rid of the gcc specific extension
as well as enforce more type safety. The conversion is not straigthforward when there are ellipsis arguments ("...") since you can't forward these arguments as-is, you have to forward them as a va_list first. This requires the generation of additionnal (inline) dce wrappers.
Sadly, there are still bugs in pygccxml/castxml which means the libc.generated.cc needs some manual editing.
Tests should be ok with gcc, they still fail with clang.
The PR changes many things but that's the only way I could find to support clang, which is quite important IMO.