From: Frank Kotler on
NathanCBaker(a)gmail.com wrote:
> On Aug 29, 8:17 pm, "H. Peter Anvin" <h...(a)zytor.com> wrote:
>> Frank Kotler wrote:
>>> Herbert Kleebauer wrote:
>>> ...
>>>> But how could they write the C library if there is no documentation
>>>> of the int80 interface.
>>> AFAIK, the C library doesn't use the int 80h interface...
>> Yes it does.
>
> I believe Frank is alluding to a recent discussion with Randall Hyde
> on the aoaprogramming list about his use of the C library as a "back
> end" for newer versions of the HLA Stdlib. IIRC, Randy maintained
> that the C library is more tightly integrated with the kernal and not
> just a simple "wrapper" for the int80 interface.

Actually, no... I know the Linux branch of HLAlib uses the int 80h
interface. I was under the impression that libc did not. I stand corrected.

Best,
Frank

From: Frank Kotler on
H. Peter Anvin wrote:
> Frank Kotler wrote:
>> Herbert Kleebauer wrote:
>>
>> ...
>>> But how could they write the C library if there is no documentation
>>> of the int80 interface.
>>
>> AFAIK, the C library doesn't use the int 80h interface...
>>
>
> Yes it does.

Okay, thanks for the correction... I think I see where I was deluding
myself - grep doesn't like "$0x80", I've gotta do "\$0x80" (I despair of
ever learning regular expressions).

> If you have a very recent glibc, then it probably uses the
> vdso interface, but that's functionally identical.

Okay... Is that related to this?

http://www.trilithium.com/johan/2005/08/linux-gate/

> You might find my klibc -- an extrememly minimal Linux libc --
> interesting for a more streamlined interface from the C API layer to the
> kernel system calls.
>
> http://git.kernel.org/?p=libs/klibc/klibc.git;a=summary

Okay... Now I see the int 80h... So if I've got the "second simplest" C
program - instead of returning from "main", it does "exit(42);"... this
goes through "__syscall_common" (arch/i386/syscall.S - in the library)?
This copies our parameter into ebx, and the sys_call number into eax,
and does int 80h, I guess.

Maybe I'm confused about this, too, but I think the int 80h vector takes
us into entry.S (arch/i386/entry.S - in the kernel code)? This looks
like it eventually does "call [sys_call_table + eax * 4]" (after putting
ebx back on the stack...). In this case, that's "sys_exit" - in
kernel/exit.c (?). That shifts our parameter up by 8, and calls
"do_exit". I'm guessing that it's the call to "schedule()" after marking
our task "dead" that actually makes us go away...(?).

Whew! I was under the impression that the C library called "sys_exit"
(say) directly, without going through the int 80h rigamarole. I was
mistaken!

So there *is* an "advantage" to using the int 80h interface ourselves?

This brings us back to Herbert's question (sorry, Herbert... and Rod...
you were right), where do library developers find documentation on the
int 80h interface? Where did you "first" learn this stuff, Peter?

Best,
Frank
From: Phil Carmody on
Frank Kotler <fbkotler(a)verizon.net> writes:
> H. Peter Anvin wrote:
>> Frank Kotler wrote:
>>> Herbert Kleebauer wrote:
>>>
>>> ...
>>>> But how could they write the C library if there is no documentation
>>>> of the int80 interface.
>>>
>>> AFAIK, the C library doesn't use the int 80h interface...
>>>
>>
>> Yes it does.
>
> Okay, thanks for the correction... I think I see where I was deluding
> myself - grep doesn't like "$0x80", I've gotta do "\$0x80" (I despair
> of ever learning regular expressions).

Are you sure it's not your shell not liking "$0x80"? Or should I
say "liking it too much"?

If you did something like
$ grep "$0x80" *

Then that first parameter's going to reach grep as ``bashx80''. Try
$ echo "$0x80"
to see that in action.

Phil
--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
-- George Bernard Shaw (1856-1950), Preface to Androcles and the Lion
From: NathanCBaker on
On Aug 30, 4:37 am, Frank Kotler <fbkot...(a)verizon.net> wrote:
> > If you have a very recent glibc, then it probably uses the
> > vdso interface, but that's functionally identical.
>
> Okay... Is that related to this?
>
> http://www.trilithium.com/johan/2005/08/linux-gate/
>
> <snippage....>
>
> So there *is* an "advantage" to using the int 80h interface ourselves?
>

It would seem a "dis-advantage" if we are to believe the blog post you
cited above.

Nathan.
From: Frank Kotler on
JC wrote:
> "Frank Kotler" <fbkotler(a)verizon.net> wrote...
> : Speaking of new versions, Agner Fog's "objconv" now has a "-fnasm"
> : switch to disassemble into Nasm syntax!!!
> :
> : http://www.agner.org/optimize/#objconv
> :
>
> Just to let everyone know, Agner updated the objconv utility today,
> Saturday, 2008-08-30.
>
> 08/30/2008 09:01 AM 12,076 extras.zip
> 08/30/2008 08:53 AM 198,944 objconv-instructions.pdf
> 08/30/2008 08:52 AM 419,328 objconv.exe
> 08/30/2008 09:01 AM 317,486 source.zip
>
> Thanks for the link, Frank. Not sure what was updated in them
> files, but a couple of Agner's files did get an update today.

Thanks for the tip, Jim! Looks like a bugfix on "fnstsw", handling for
"st0" vs "st(0)", "xmmword" -> "oword", "ymmword" -> "yword" (matches
Nasm syntax better, dunno about others). Should make it work better...

I notice his "asmlib" has been recently modified, too. I haven't looked
at that much, except to observe that it's heavily "macroized" - uses
that "$ = $ - 1" trick that Nasm won't do... Should be some really
interesting code to study, but I find it hard to read...

Best,
Frank