I'm looking for a libc implementation in a single C source file.
Previously, I tried decompiling musl's libc.so with Ghidra but the result contained too many errors. Even after manually fixing these errors the result is too far removed from the original source code for my needs.
I found this but I was hoping to find something more complete. For example, including some of the math.h functions and printf.
Then today I found a mention of the VAX/VMS C compiler in a comment on this answer which states:
The VAX/VMS C compiler kept all the C runtime library headers in a single textual library file (similar to a unix archive), and used the string between the < and > as the key to index into the library. –
Adrian McCarthy
Feb 15, 2017 at 23:14
This might fit my needs, if the "textual library file" contains C source code.
So primarily I'm looking for a single-file libc.c implementation. But if someone has a link to this VAX/VMS C compiler archive file, I'd be interested in that too.
Related
Suppose that there is a simple binary that depends on three libraries, libA.so, libB.so, and libC.so. In the usual case, these three dependencies would show up in readelf as needed. However, I am curious about whether it is possible to make a shared library libABC.so that does absolutely nothing but act as an interface to the three actual libraries by "redirecting" the symbols. This way, perhaps one can have multiple versions of libABC.so that in turn point to different versions of the three dependencies, and the binary can "depend" on just libABC.so. Is this possible with ELF?
Another possible use case is the inverse, when the binary already depends on an existing library libABC.so that just so happens to have become split up into three individual libraries.
Beware that I do not necessarily have a practical use or actual use case for this. Whether or not the above example cases are practical, I am merely curious about the possibility.
Re-export Shared Library Symbols from Other Library (OS X / POSIX) has a promising title, but the answers seem either Darwin-specific, or do not quite answer this question.
That kind of works with ELF because of the flat namespace of symbols: if you're depending on one library you usually get access to the symbols of its dependencies at the same time (the exception being when dlopen() is used).
But most link editors (ld) do not do that by default (anymore), because it would let unneeded libraries to be added to the dependencies otherwise. In GNU ld the feature is controlled by the --as-needed flag, and was turned on around 10 years ago by default if I remember correctly.
You should be able to force the behaviour you're looking into with GNU ld by linking (e.g. via the GCC frontend) with gcc yourprogram.c -Wl,--no-as-needed -lABC -Wl,--as-needed. That will force linking to libABC.so whether the program is using one of its exported symbols or not.
I have written extensively on the feature, because it solved many problems for distributions at the time, on my blog if you're looking into what the practicalities of it are.
I'm looking into installing a disassembler (or decompiler) on my Linux Mint 17.3 OS and I wanted to know what the difference is between a disassembler and a decompiler. I have a rough idea of what they are (the names are fairly self-explanatory), but they are still a bit confusing.
I've read that a disassembler turns a program into assembly language, which I don't know, so it seems kind of useless to me. I've also read that a decompiler turns a 'binary file' into its source code. What exactly is a binary file?
Apparently, decompilers cannot decompile to C, only Python and other similar languages. So how can I turn a program into its original C source code?
A disassembler is a pretty straightforward application that transfers machine code into assembly language statements - This activity is the reverse operation that an assembler program does and is straightforward because there is a strict one-to-one relationship between machine code and assembly. A disassembler aims at a specific CPU. The original assembler that was used to create the executable is only of minor relevance.
A decompiler aims at recreating a compiled high-level language program from machine code into its original format - Thus trying the reverse operation of a C or Forth (popular languages for which de-compilers exist) compiler. Because there are so many high-level languages and thus so many ways in how original high-level language constructs could be expressed in machine code (even a lot of different strategies for the same language and construct, even in the same compiler, and even different strategies depending on the compiler mode and situation), this operation is much more complex and very dependent on the original compiler (and maybe even the command line that was used, it's chosen optimization level and also the used version).
Even if all that fits, most of the work of a decompiler is educated guessing and will most probably never reach a point where it can reconstruct the original program in its source code form 100% - It will rather end up with a version of source code that could have been the original program.
I tried to configure perl-5.18.2.
In checking C library phase, I got following messages.
Checking for GNU C Library...
You are not using the GNU C Library
I can use /mingw/bin/nm to extract the symbols from your C libraries. This
is a time consuming task which may generate huge output on the disk (up
to 3 megabytes) but that should make the symbols extraction faster. The
alternative is to skip the 'nm' extraction part and to compile a small
test program instead to determine whether each symbol is present. If
you have a fast C compiler and/or if your 'nm' output cannot be parsed,
this may be the best solution.
You probably shouldn't let me use 'nm' if you are using the GNU C Library.
Shall I use /mingw/bin/nm to extract C symbols from the libraries? [y] /mingw/bi
n/x86_64-w64-mingw32-nm.exe
I can't seem to find your C library. I've looked in the following places:
/lib
/usr/lib
None of these seems to contain your C library. I need to get its name...
Where is your C library?
Where is my C library?
I've tried /mingw/bin/nm.exe too.
http://search.cpan.org/dist/perl-5.18.2/README.win32:
The INSTALL file in the perl top-level has much information that is only relevant to people building Perl on Unix-like systems. In particular, you can safely ignore any information that talks about "Configure".
Instead, follow the instructions in the README.win32 file.
When I type 'f' in a C source file, my emacs with semantic installed and working
will show 25 completion matches, for functions like fclose, fread, and so on (only stdio.h
included)... but not fopen! Why?
Plus, same problem with opendir and readdir, with sys/types.h and dirent.h included.
P.S. semantic has all my sympathy, as upon my personal reading glibc header files showed
as a horrible mess of #ifnded and alikes.
'fopen' is turning up fine for me. Are you by any chance working on OS X? I remember that there were some preprocessor macros there which confused Semantic. Otherwise, your best chance for help is posting to the CEDET-devel mailing list, stating the CEDET version you're using and posting the exact definition of the 'fopen' function which apparently cannot be parsed.
I write 3 .lex files for 3 different format file parsing, after generating scanner c code, I need to build these 3 file into a single executable but it failed for reason like “multiple definition of ＇yy_switch_to_buffer（...）＇”, “multiple definition of ＇yytext＇”, ...
How to solve this？
(Answered by the OP in a comment. Converted to a community wiki answer to suit the Q&A style of Stackoverflow.)
The OP wrote:
Use the %option prefix=“zz” to replace the default functions with zz-prefixed macros. Also ylwrap in autotools seems only handle scanner C file named lex.yy.c, so %option outfile=“lex.yy.c” is needed too.