[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] MiNT lib 55
Hi,
> To answer your question: The old code
>
> file->_flags |= _IOBIN;
> file->_flags &= ~_IOBIN;
>
> now translates to
>
> file->__mode.__binary = 1;
> file->__mode.__binary = 0;
Thanks a lot. :)
>
> > 2) Where the macro S_IFBLK is defined (in PL 49 it was)?
>
> See reply to Q-Funk. Add -D_BSD_SOURCE to your CFLAGS and then read
> NOTES. ;-)
Sorry, my mistake: I meant S_IFSOCK... and also sys/types.h seems to
define ushort and ulong, but doesn't define uchar, which is a bit
annoying. And mintbind.h doesn't define Slbopen()/Slbclose().
> > #include <mintbind.h>
> >
> > int
> > main()
> > {
> > Cconws("Dupa blada\r\n");
> > return 0;
> > }
>
> Become an ld wizard! ;-)
> I can link that into a file of less than 400 bytes. It would be less
> than 20 Bytes without the header and the relocation info.
I think i would be satisfied with 400 bytes. Okay, nice to know that it is
possible :)
> > which does not contain a single library reference, has exactly 39
>
> Sure it contains library references: _start, __main, _environ, ...
Nope, it doesn't. I am explaining: i didn't use any library function, so
it does not have rights to contain any single library reference.
> The reason for that annoying size problem is simple to find and hard to
> solve. The startup code contains a lot of library references and drags a
> lot of seemingly unused modules into the link. In "normal" applications
Well, I can't imagine why the startup code, which basically has to shrink
the mem and parse the commandline, and this is rather simple task, has to
use a lot of library references and finally become 40k in size.
> this is not such a big problem because you will reference most of it from
> your application code as well but in pathological cases like your
> three-liner it is a nuisance, that's right.
I disagree. Even a complex program can be written without many references
to the library. I actually have one such program, which has four modules
of less than 2k each (after compiling downto *.o files) and is basically
using strcpy(), strstr(), strlwr(), strcat() and printf(). Even
considering the printf() may be large, I still don't understand why the
final binary has over 100k. I suppose 70k of this just wastes disk and
memory space.
> I have already given a lot of reasons for the larger binaries in a
> previous thread. In brief: Old MiNTLib versions had countless bugs which
> turned up when I added the test suite to the MiNTLib. The most common
> reason for the bugs was that the old code was too simple, ignoring a lot
> of special cases or tolerating bugs. I have tried to overcome that either
> by adding code for special cases or by updating the sources to newer
> versions from other sources which had fewer bugs, more features and which
> are mostly bigger.
I don't deny the fact that a better library is larger. I am trying to
point out, that nothing (or very little) of that should be linked to a
program that DOES NOT WANT TO USE THE LIBRARY. Writing a program in C I am
expecting, that the linker will produce something executable, and
particularly I don't want it to present me gifts in a form of linked stuff
which I don't use, don't want to use and don't want to see in the
executable.
Frank told me, that dropping the code, that emulates stuff on poor systems
would make the library dramatically smaller. So, the library is big,
because it emulates MiNT features on TOS and MagiC. My question is, why a
MiNT only program, which does not have a chance to work under TOS or Magix
(ssh for example, or pine, or syslogd, or init, or whatever needs
mintnet) has to carry all this stuff inside? This is not a stupid
question, because the current situation is that MiNTlib is used as libc
for gcc, so it is mainly used to compile programs which run under MinT,
then again, non-Minters don't use MiNT Library, because it is a) too big,
b) current versiosns of gcc don't work under anything but MiNT.... So the
presence of the code that emulates MiNT functions seems like a serious
paranoia.
And even if tossers and magicers would use mint library for something, I
still don't uderstand why my init (which is resident in the memory all the
time the system is up) has to contain code that emulates
e.g. vfork() under TOS...
> Then, in the last couple of months there have been a lot of improvements
> been done to the kernel. Have a look at files like stat.c. It contains
> four fully-featured versions of stat(). If I wouldn't have to emulate
> every second call for dumb systems like Magic the MiNTLib would be a lot
> smaller.
See above.
> You will agree that an extra 30 or 40 kBytes wouldn't count at all if the
> MiNTLib was a shared library. But the MiNTLib won't become a shared
> library in just a day and in the meantime you either have to live with the
> larger code or you have to stick with an older version. Don't ask for a
> bugfix-only version. Bugfixes generally result in bigger code; that's
> what I am trying to explain.
This wasn;t the question. The question was, why a lot is linked when
nothing was used...
> > 4) Why a simple program after compiling and linking with "-pg", once run,
> > immediately gets killed by the code in bios.c, which protects the
> > system against changing an exception vector into private memory? And
> > simultaneously cursor stops blinking, what is the normal MiNT reaction
> > after the GEMDOS timer vector gets unhooked. Do profiling functions of
> > the library use GEMDOS timer? What for, and why (apparently)
> > changing something directly, not via Setexc()? And BTW. doesn't MiNT
> > have interval timer especially for e.g. profiling?
>
> Profiling worked here after some changes in the code and some changes in
> libgcc (not tested with the latest kernel). I will re-check that. If
> profiled programs crash again, I'm sorry. I really spent a lot of time to
> make it run again.
I believe the profiling worked, but the question is why it links the
GEMDOS timer, because if it is intended to do so, it will never work on
systems with memory protection enabled (because GEMDOS timer vector cannot
point to programs private text segment; yet bios.c should kill such a
program, but it doesn't which means that the gcrt.o or whatever touches
the GEMDOS timer, does not do it cleanly, i.e. via Setexc()).
Gtx,
--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org
** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.