Anyone knows where can I find the floating functions for non FPU processor (SH-3) called __mulsf3, __divsf3, __addsf3, __subsf3, __ltsf2 and __floatsisf. I read that those functions are in libgcc but linking against libgcc does not work. Also I read that SH3 devs moved those functions to another lib (maybe libfloat or libgcc_os).
Anyone has a clue? I would prefer to have a look at the source.
Thanks!
If I'm not mistaken, many of these are generated during GCC's build process and they are highly dependent on system and architecture.
What I do know for sure it that LLVM's compiler-rt strives to provide an alternative. The sources are located here:
http://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/
The implementation details have changed over time, but they're supposed to be in libgcc. However, SH being a multilib system, maybe you're trying to link to the wrong libgcc?
Related
So I have enabled -fsantize=address to write a good program.
However, quite a bit of issues was being caught by other libraries that are not written by me (for ex, /lib64/...so)
I looked into -fsantize-blacklist option but seems like it's only available for clang not for GCC.
I know you can blacklist specific functions in your source code. But to be honest, that is not the ideal way as I wouldn't know which function will cause the issue ahead of time.
Is there any way to prevent GCC from processing address sanitizer for files under a specific folder?
Please help :(
Unfortunately fsanitize-blacklist has been rejected by GCC maintainers several times and there's no equivalent option. You could add Clang support or use -fsanitize-recover=address together with export ASAN_OPTIONS=log_path=path/to/logs to collect errors from all libraries and then filter the ones that are relevant.
I need to link my SO against libbfd, for the purpose of having human-readable backtraces.
Static linking against libbfd.a fails, because it's not compiled with -fPIC, so as I understand, it can participate in executable only.
Though linking against libbfd.so also gives some troubles.
I need to compile on both Ubuntu-14.04 and Debian Wheezy 7.8
And they have non-intersecting sets of binutils versions. In particular, Ubuntu has 2.24, and Debian has 2.22 and 2.25. And the problem is, gcc doesn't want to take symlink's name libbfd.so to reference it, and uses SONAME instead. So i end with either libbfd-2.24-system.so or libbfd-2.25-system.so in dependencies.
For now I see several approaches:
There's some hidden flag which allows to override SONAME during linking. This is the preferred path
I have no way other than compile libbfd by hand. I would evade this as much as possible.
Manual dlopen+dlsym for everything I need.
I read answer gcc link shared library against symbolic link, but it suggests to change SONAME I'm not able to do.
Any suggestions?
Thanks.
EDIT: it seems that virtually all static libs in Ubuntu repos are not position-independent. Can't guess why. With the inability to override SONAME it makes things much more complicated.
Not sure whether i understand your (4 years old problem) correctly, but having similar problems with libbfd, I found this solution:
Using the linker flag -lbfd seems to work.
It is a linker flag that specifies g++ to link against libbfd.
My full command was g++ loader.cc -lbfd.
At least for me, errors at link-time a la "unknown function" are solved.
It is needed to gather the necessary information about the translation unit using the plugin for GCC and to modify AST on its base.
I've already understood how to gather information. But I haven't understand yet how to modify AST before it's passed into CRT. Very little information is available on this subject.
Tell me plese what should I read on this subject? Share thoughts, links.
Thank's.
P.S.
I've already read everything on these links:
http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Print_version
http://developer.apple.com/library/mac/#documentation/DeveloperTools/gcc-4.2.1/gccint/index.html#Top
The GCC test suite contains a basic examples of such modifications. See http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/plugin/finish_unit_plugin.c and start_unit_plugin.c shows how to create a var. Unfortunately for more serious modifications the GCC source code are probably your best bet.
Are you tied to GCC for this endeavor? The ROSE compiler is built specifically for performing source-level modification, then handing the resulting code off to a backend compiler.
Can any one of you help me in converting an windows dll file in a .so file.
You might try re-compiling the source code to the dll to a shared object. This may help you get started, after ensuring the code is indeed portable.
Edit:
Here is yet another link that can help guide you through the process of creating a shared library using GCC and other parts of the GNU tool chain. This link will help you to discover pitfalls that other people had when undertaking a project similar to this.
There is only so much help that can be provided for such a specific task, especially with so many unknowns. If you elect to provide more information in your question, please leave a comment.
NB: I'm pulling these links right out of Google.
If you don't have the source, or can't recompile, you may be able to run the code under Wine.
You need to recompile again into an .so file.
This question must apply to so few people...
I am busy mrigrating my ARM C project from Winarm GCC 4.1.2 to Yagarto GCC 4.3.3.
I did not expect any differences and both compile my project happily using the same makefile and .ld files.
However while the Winarm version runs the Yagarto version doesn't. The processor is an Atmel AT91SAM7S.
Any ideas on where to look would be most welcome. i am thinking that my assumption that a makefile is a makefile is incorrect or that the .ld file for Winarm is not applicable to Yagarto.
Since they are both GCC toolchains and presumably use the same linker they must surely be compatable.
TIA
Ends.
I agree that the gcc's and the other binaries (ld) should be the same or close enough for you not to notice the differences. but the startup code whether it is your or theirs, and the C library can make a big difference. Enough to make the difference between success and failure when trying to use the same source and linker script. Now if this is 100% your code, no libraries or any other files being used from WinARM or Yagarto then this doesnt make much sense. 3.x.x to 4.x.x yes I had to re-spin my linker scripts, but 4.1.x to 4.3.x I dont remember having problems there.
It could also be a subtle difference in compiler behavior: code generation does change from gcc release to gcc release, and if your code contains pieces which are implementation-dependent for their semantics, it might well bite you in this way. Memory layouts of data might change, for example, and code that accidentally relied on it would break.
Seen that happen a lot of times.
Try it with different optimization options in the compile and see if that makes a difference.
Both WinARM and YAGARTO are based on gcc and should treat ld files equally. Also both are using gnu make utility - make files will be processed the same way. You can compare the two toolchains here and here.
If you are running your project with an OCD, then there is a difference between the implementation of the OpenOCD debugger. Also the commands sent to the debugger to configure it could be different.
If you are producing an hex file, then this could be different as the two toolchains are not using the same version of newlib library.
In order to be on the safe side, make sure that in both cases the correct binutils are first in the path.
If I were you I'd check the compilation/linker flags - specifically the defaults. It is very common for different toolchains to have different default ABIs or FP conventions. It might even be compiling using an instruction set extension that isn't supported by your CPU.