## Writing a custom libc

c

### Writing a custom libc

where can I get the pieces needed to write a custom C library? I ask
because I'm working on a rather large set of libraries where the extra
stuff in glibc is a waste of space.



### Re: Writing a custom libc


Eh?  Not including stuff you don't use is the linker's job.

--
Ian Collins.


### Re: Writing a custom libc



a program that never uses any of the <locale.h> functions
but uses <ctype.h> might drag in a whole bunch of the locale
machinery, because the <ctype.h> facilities are sensitive to
the locale changes the program will never perform.  Also, the
use of shared libraries tends to make library inclusion an
all-or-nothing proposition -- although in this case, the amount
of space used in the entire system usually decreases even if
the amount "used" by a single program seems to be greater than
if it incorporated only the "necessary" functions.

If the O.P. has actually measured the amount of "extra
stuff" and found that it can't be tolerated (highly unlikely;
if he'd measured anything he'd probably have mentioned it),
there are a couple of possible strategies.  First, he could
see whether his system supports "static linking," following the
model implicit in Ian Collins' post.  If that's not enough, he
can get hold of the glibc source and start throwing things out
until he's got a smaller (maybe), less functional (surely), and
non-conforming (probably) library that works for his program
but for few others.  And I bet it won't save him much, either.

--
Eric Sosman
XXXX@XXXXX.COM


### Re: Writing a custom libc



You *do* realize you've given me the answer don't you? All I have to do
is write a new locale that can handle braille and patch the aclocal.m4
and Makefile to a) skip the threading and use sockets. b) use the
braille-enabled locale as the default.

thanks!



### Re: Writing a custom libc



Assuming you are running linux: other C libraries with a much smaller
footprint exist, take a look at uClibc.

--
:wq
^X^Cy^K^X^C^C^C^C


Hello,

Could someone help to explain some of the wording for R6RS reagarding
custom binary output ports?

The specification of the writer for the custom port indicates that when
passed a count of zero, this should be the same as asking the write
procedure to send the eof of file "object" to the byte sink. However, the
R6RS EOF object defined by R6RS is that object returned by 'eoj-object',
which by definition has no external representation and is not a datum.
Moreover, the write procedure is required to indicate the number of bytes
that were actually written. This number should not be, according to my
reading, more than the count argument that is passed to the write
procedure. Yet, in the case of the zero count argument, we are required to
write something, which means at least one byte, to the byte sink. This to
me indicates that the write procedure must return at least 1 in all cases.

There are two traditional EOF characters in common use today, the CTRL-D
from UNIX, and the CTRL-Z from windows. Does R6RS actually mean that one
of these characters should be send to the sink? If so, which one? Should
be base this on the platform which is sending the data, or the platform of
the system receiving the data? These can be different systems, as in the
case of sockets or network communication, and thus, who knows whether one
or the other should be considered?

Additionally, there is no facility for sending this character outside of
using something like #\x4 to send it. If R6RS really intended to use a
character for sending the EOF object over the
stream or byte sink, wouldn't it make sense for the R6RS to at least
define the #\eof or #\end-of-file character so that this could be done in
a portable way. Even without this, at least something like an
'eof-character' parameter could have been made.

The complete lack of information available on this in the documents
suggests that I have misread something. Could someone provide more input
as to the proper behavior of these procedures when they are passed a zero
value for their count argument?

As a side, I also know that in Linux, the write(2) system call has
unspecified behavior with a zero count argument when the file descriptor
is not a regular file.

Aaron W. Hsu

--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis


> You mean this source code right here:
>
>
> [ClassName: B$'RosAsmWindowClass' 0 EditClassName: 'EDIT' 0 > AppName: ' RosAsm, The Bottom-Up Assembler for ReactOS -V.1.22b-' 0] > <<<<<<<<<<<<< In case you might have missed it: The snippet above is a data declaration in RosAsm. The fact that something is named EditClassName does not mean that it is used as a base class for any window. If you retry that test Donkey did with your favourite Spy tool you see that the source editor is of class 'RosAsmWindowClass'. If it was reported as Edit in the past, this only reflects that you can give your custom classes existing names (which is new for me, too). Or would you expect that the *Scrollbar* in RosAsm is of class Edit? Besides that: Who cares? :) Ludwig  Betov wrote: > XXXX@XXXXX.COM rivait > news: XXXX@XXXXX.COM : > > > Well, i should not answer to this flow of insanities, > but, maybe it would be possible that some readers > could believe them. So... here we go... > And you really expect people to believe you? Let me clue you in, Rene, you have zero credibility. It comes from spending five years around here spouting nonsense. Feel free to take your credibility level into the negative regions, though. > > We have never seen a "preparser" outside of RosAsm, either. > > One more inovation of RosAsm, that you will probably > never understand. IOW, a preparser is bad in HLA, it's an innovation in RosAsm. I love it! > > >> RosAsm users' ones are (very partialy) there: > > > > Who cares? That has nothing to do with whether or not RosAsm is or > > isn't an assembler. The fact that you've collected a few user demos on > > your web page is hardly what defines what is and is not an assembler. > > Sure, but there is no question about RosAsm being or > not being an Assembler. Everybody knows that RosAsm > is an Assembler, full right, and this has never been > a question. No, by your own definition RosAsm fails to be an assembler. That point has been made around here many times. It's not a question of whether RosAsm is or isn't an assembler, though. What is in question is your lame definitions, which you attempt to use to claim that MASM and HLA are not assemblers. The problem with your definitions is that, when applied to RosAsm, they demonstrate that RosAsm isn't an assembler, either. You know, few people (other than the RosAsm crowd) question that MASM is an assembler. You do. That fact alone gives you zero credibility when it comes to defining what is and what is not an assembler. > > As opposed HLA is evidently not an Assembler, at all, > as it does not even include an Encoder, and as it does > not conform to any possible definition of what any > Assembler could ever be. It most certainly does include an encoder. Under Windows, it's called ml.exe or fasm.exe. Under Linux, it's called as. The fact that it is a separate process is irrelvant. > > > > As for the fact that RosAsm's demos may be more advanced than some > > user-written HLA demos, that's pretty much a given at this point. The > > HLA user base is built up of beginning programmers. It will take time > > before the larger user base increases to the point where you find a > > large number of HLA apps as you would, say, MASM apps (the RosAsm base > > is so pathetically small, I'm certainly not setting my goals to > > achieve that level). > > :)) > > OK: > > 1) This is normal that the HLA victims have nothing to > show, because they are all beginners. Yes, that is the market for whom HLA was created. Most HLA users are solving homework problems and the like with HLA. Not exactly the stuff you post on web pages (for obvious plagiarism purposes). > > 2) This is normal that the RosAsm users have something > to show because they were all experts before using RosAsm. > (What means that RosAsm does not have any beginner user). Again, you are quite correct. Very few beginners could learn with RosAsm because of the lack of appropriate pedagogy (and the prime example of a beginner, Wannabee, is quite scary). I'd bet that the largest percentage of RosAsm users already knew assembly upon encountering RosAsm and, for whatever reason, were willing to learn a different syntax (perhaps to use the IDE, back in the days when Spasm was the only game in town) in order to use RosAsm. It's not surprising, therefore, that *some* more advanced demos have come from the RosAsm crowd. Then again, now that we have IDEs for the likes of NASM, FASM, MASM, and HLA, the advantage you once held in that area no longer exist. Compare yourself with the number of demos written by advanced users of *other* assemblers (NASM, FASM, MASM, and even Gas). You've got a pathetically small number by comparison. > Fancy... :) Nothing fancy about it at all. RosAsm has a tiny number of demos available, compared to MASM, NASM, FASM, etc. Comparing yourself against a teaching tool, for whom most users will complete the assembly course and then simply use assembly in support of their HLL code may make you feel better, but it doesn't change the fact that *you* don't have a whole lot of people using your product. HLA *has* reached critical mass. There are lots of people using it and the experience of the user base is increasing. No doubt, within a year or two, the number of user demos and applications written in HLA will surpass that of RosAsm. You've got an advantage right now insofar as HLA's user base has been inexperienced. But that advantage is fading fast, just like all the other advantages RosAsm has held in the past (such as being the first with an IDE). Not that having more "user demos" has really been much of an advantage to begin with. What does it prove? Absolutely nothing. Again, if you had the same number of apps as MASM, I'd be impressed. Trying to impress us with the tiny number of apps that you've got simply demonstrates how *small* you think. > > > > I guess Guga doesn't either. How's the disassembler coming along? > > Can't make any progress on it on your own? > > Yes, I have already answered to this. You will see the > next coming release, with significative improvements, > in the next week, probably. I'd say I'm looking forward to it :-). But the truth is, you keep making the pronouncements about how great the disassembler is, and every time I've played with it, I've broken it within a minute or two. Though it has been a long time since I've played with it, I'm not expecting much. > > [By the way, not to minimize Guga contribution -that > is quite massive on many areas...-, Guga never wrote > _one_ single line of the Disassembler, that is 100% > my own work. Though this may change in the future, > for the final HLL interpretations... :)] Yet, you've claimed in the past that work was being held up while Guga was busy moving. Perhaps you can explain those posts? > > Yes, we were *all* impressed by his last set of claims about how he > > rewrote the Delphi VCL. They were about as amusing as your claims that > > you'd created a totally custom edit tool for RosAsm. > > If "Half claims" were "as amusing as", i suppose he > was 100% right, as long as it would require really > having a very damaged brain, to assert that RosAsm > Sources Editor is not "a totally custom edit tool > for RosAsm". Shall we ask Donkey to step in and point out how your code is just a subclass of the Win32 tool again? You do realize, of course, that by making RosAsm GPL and posting the source code, it's pretty easy for people to verify what you've done with respect to your EDIT tool? Make all the proclamations you want about your "totally custom edit tool", but anyone who looks at your source code can easily determine that you've simply subclassed the Win32 tool. In most people's minds, that not a "totally custom edit tool". > > Anybody taking a quick look, simply, to the way the > Sources Editor works, can see immidiatly that it is, > in no way, an Edit Control, and anybody taking a quick > look to the Source of the Sources Editor can see that, > effectively, it is a 100% original Editor making use > of nothing but the "TextOutA" Function, with many > unusual Functionalities. Yes, I do believe that Donkey did this, and verified that you are simply subclassing the existing tool. Hardly a "totally custom edit tool". > > Saying that i don't know what RosAsm Sources Editor > is, and how i wrote it, shows nothing but your vileny > and your definitive stupidity. I will certainly admit that *I* haven't wasted the time figuring out what you've done. But I have a fair amount of respect for Edgar (Donkey) and he made a very pervasive arguement in this very newsgroup that pretty much debunked your claims that you wrote a "totally custom edit tool". Perhaps you simply don't understand the meaning of the phrase "totally custom edit tool"? > > Well... you know, when Half will have finished his > Icon Editor (w<e should have a new release soon...), Wait, wait, wait. I thought he wrote this in 12 days, or something like that? You mean, it's not finished? Boy, it's been a couple of months now. You know, this "demo" is looking less impressive with each passing day. > everybody will be able to measure the exact value of > your words. Yes, they will. > >> No. It does not. What does damage Assembly is when writing > >> Applications with a weird HLL and saying that it is Assembly. > > > > You mean, like RosAsm? Whether you claim HLL-like control structures > > are macros or not in RosAsm, the bottom line is that you use a > > HLL-like programming style in RosAsm. The fact that you call those HLL > > statements "macros" doesn't change one thing. The fact that those > > macros are built into MASM, TASM, and HLA doesn't mean a single thing > > to your average assembly language programmer. What they see is that > > you use HLL-like control structures in your code and then complain > > about their presence in other assemblers. Doesn't make much sense to > > most people (then again, neither do most of your posts). When you give > > up the HLL-like programming style in your RosAsm code, you'll have a > > leg to stand on when you make this complaint. Until then, it's all > > syntactical nit-picking with absolutely zero differentiation between > > the products (other than the fact that MASM, TASM, and HLA do a much > > better job of what you're trying to do with your macros). > > Just for the ones reading those bullshits: > > Writing an HLL Pre-Parser enabling HLL Statements is > way easier to write, than writing the Macros Parser > that can enable the Programmer with defining his own > HLL Style. HaHaHaHaHa! So why don't you prove how easy this is by writing such a "preparser" for RosAsm then? Given how broken your macro system is, such a "preparser" would be a boon to RosAsm users. BTW, have you forgotten that HLA *also* includes a powerful macro system that is *far* more capable of implementing those HLL-like statements than is RosAsm? Indeed, I've provided sample macro implementations for *every one* of the HLA high-level control structures. So if macro implementation is really a good indication of the power of the assembler, HLA still wins hands down, because the macro implementation of those statements in HLA is *far* better than that in RosAsm (none of the funky "." nonsense, fully recursive, full boolean expressions, nestable to any level, etc., etc., etc.). > > That is, by the way, one of the major differences > between a Compiler and an Assembler, Actually, there is an element of truth to this. Which is one of the reasons I refer to HLA as a "compiler for an assembly language." On the other hand, your argument that having the macros built into the language puts you on weak ground. After all, RosAsm is the assembler that builds all the Win32 equates into the assembler (rather than including them as part of the user's source code as all other assemblers do). So I'd be careful about your claims of what an assembler is and isn't. As usual, they can be easily turned against you. > that this swindler > could never admit, as long as he is utterly unable to > write anything but an HLL pre-parser. Whatever you say. Bottom line though, is that I've written a lot more code than you ever have, both in assembly and in HLLs. Cheers, Randy Hyde  I was wondering whether there is much difference between the draft standards of C and the official ISO published standards. For example, would the draft standard be good enough to go on when writing a new ISO Standard C compiler and C library? Could the drafts be used as a reference when writing C programs without any problems caused by differences between the draft and the standard? Thank you, -- James Buchanan  I am trying to figure out how to link to libc in assembly -- I just want to know how to do this. The documentation I find online is for linux, but I am using one of the BSDs. Anyway, here was my process: 1) write C code with printf: #include <stdio.h> int main() { printf("hello\n"); exit(0); } 2) compile and link the C code 3) lld the C code to see what libraries I need:$ ldd library
library:
Start            End              Type Ref Name
0000000000000000 0000000000000000 exe   1  library
0000000048aaa000 0000000048f7e000 rlib  1
/usr/lib/libc.so.38.0
0000000042200000 0000000042200000 rtld  1  /usr/libexec/ld.so

4) write the assembly code:

# writes an arg to stdout

.section .data

.section .text

.global _start

_start:

xorq %rax, %rax
movq 16(%rsp), %rdi # arguments are stored %rsp+16
call printf

movq $1, %rax movq$10, %rdi # just messing around with error return values
syscall

5) assemble and link the assembly code:

as -o test_arg.o test_arg.s
ld -dynamic-linker /usr/libexec/ld.so -o test_arg test_arg.o -lc

/usr/lib/libc.so.38.0: undefined reference to environ'
/usr/lib/libc.so.38.0: undefined reference to __progname'

Is there something obvious that I am doing wrong?

Thanks,

Brian