最近のLinuxカーネル（少なくともamd64）は、カーネルにsyscallインタフェースを抽象化して、カーネルが最適な呼び出し規約を選択できるようにする、linux-vdso.so.1というマジックオブジェクトファイルを提供します。 Cでコードを書くと、glibcは自動的にこのオブジェクトを使います。独自のプログラミング言語でVDSOオブジェクトを活用するには？
今、glibcを使用せずにプログラムを作成したい場合は、このオブジェクトをどのように使用できますか？それが提供するインターフェイスはどこかに書かれていますか？呼び出し規約はどうですか？
か否か。
あなたの言語は、あなたがVDSOを使用する必要はありませんCラッパースルーすることなくシステムコールへの直接アクセスを提供した場合は（あなたは、例えばシステムコールを行うために、適切なSYSENTERマシン命令を生成することがありました）。その場合、あなたの言語は、カーネルの規則だけで、すべてのABI規則に従う必要はありません。 （たとえば、レジスタにABIが呼び出したcaller-safe calle-safeの区別を必要とせず、スタックの使用を避けることさえできます）。
私は、x86プロセッサのさまざまなファミリ間でsyscallを実装する際に、さまざまな小さな相違（ユーザ - >カーネル遷移に関連する）を抽象化することを、カーネルが提供する抽象化であると考えています。特定のプロセッサターゲットを選択した場合、VDSOは不要であり、常に回避することができます。
AFAIU、VDSOはELFの共有オブジェクトで、ffffffffff600000-ffffffffff601000セグメントに（最近Debian/AMD64でコンパイルされた3.8.3カーネルで）座っています。それがどこにあるか正確にcat /proc/self/mapsで確認してください）。したがって、ELF共有オブジェクトの構成を理解し、そこからシンボルを取得するだけで済みます。 this & thatリンクを参照してください。 VDSOは、x86-64 ABI仕様で文書化された呼び出しのためのC規則を使用します。
あなたのプロセス空間VDSOから抽出して、ディスクファイルにそれを書いた場合、結果がうまく形成されELF共有オブジェクト
ELFであることは十分に文書フォーマットである、です。また、x86-64 ABI conventions （正確にはCの呼び出し規約と、プロセスのイメージがどのように正確に定義されているか、execve(2)も参照）のマニュアルページともちろんカーネルのドキュメントもあります。私はELFの理解に時間がかかることに同意します（私は10年前にそれをしましたが、記憶は錆びています）。お使いのマシンの<elf.h>ヘッダーファイルもお読みください。
たとえば、実行（zsh 64上のビットの下のDebianのx86-64）
% file $(which sash)
/bin/sash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, for GNU/Linux 2.6.26,
BuildID[sha1]=0x0347fcc08fba2f811f58af99f26111d0f579a9f6, stripped
% ldd $(which sash)
not a dynamic executable
% sash
Stand-alone shell (version 3.7)
> ps |grep sash
21635 pts/3 00:00:00 sash
> cat /proc/21635/maps
00400000-004da000 r-xp 00000000 08:01 4985590 /bin/sash
006da000-006dc000 rw-p 000da000 08:01 4985590 /bin/sash
006dc000-006e1000 rw-p 00000000 00:00 0
017e3000-01806000 rw-p 00000000 00:00 0 [heap]
7fe4950e5000-7fe4950e7000 rw-p 00000000 00:00 0
7fff3f130000-7fff3f151000 rw-p 00000000 00:00 0 [stack]
7fff3f173000-7fff3f175000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
も参照this answer。
VDSOを単純に解析できるダイナミックリンカの最小限のバージョンが必要になるでしょう。あなたは、プロセスが始まる正確な状態、特にauxvという補助ベクトルの役割を理解したいと思います（これらの詳細は忘れてしまいますが、重要です）。例えば、 this article
実際、ランタイムを確実に開始することは、おそらくVDSOの問題よりも困難です。
あなたはまた、また、いくつかのことを説明する（ただし、x86-64でよりx86の詳細）linux assembly howtoを読むことをお勧めします
ところで、（代替libcのある）http://musl-libc.org/のコードが読みする方がはるかに簡単ですし、私が参考にLinuxカーネルツリー内のこれらのファイルを見つけ
glibcの一部を使用せずに、プログラミング言語用のランタイムライブラリを実装しようとしています。私は、裸の命令をラップするシステムコールのためのプリミティブが必要です。私はシステムコールを実行するのに利用できる最も速い方法を使用するので、速度のためにVDSOを使用したいと思います。 – fuz
次に、最初に設計して実装し、後で最適化します。 VDSOは最適化であり、実際には特に新しいプログラミング言語ではそれほど重要ではありません（ほとんどのプログラムはシステムコールにバインドされていませんが、ユーザーCPUまたはIOにバインドされていません）。 AFAIKは、静的にリンクされたバイナリ（たとえCでも）がVDSOを使用していないとしても、アドレス空間に残っています。 –
あなたの答えとあなたのコメントは私の質問のいずれにも対処しません。「Howto A」と答えたら、基本的に「Do a A later」です。 – fuz
は、インターネットを掘りに私は、このリンク
http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken
私はそれがあなたの質問に答えると思うが見つかっ
あなたの実装が Cに低レベルのユーティリティのためのインタフェースを使用している場合、それが依存この記事は一切役に立ちません。カーネル側のVDSOにシステムコールを追加する方法について説明します。既にリンクされている場合にオブジェクトを取得する方法を除いて、ユーザーランド側についてはほとんど何も言いません（glibcなしでコンパイルした場合はそうではありません）。 – fuz
VDSOはGlibcがなくても魔法のようにリンクされています。あなたは他のLibcがそれをやっていることを理解することができます。 http://musl-libc.org/のソースコードは非常に読みやすくなっています（Glibc以上に多くのプリプロセッサトリックを使用しています）。 –
@Basileオブジェクトファイルを-nostdlibでコンパイルし、ldd a.outを実行してリンクされたlibsをダンプします。 linux-vdso.so.1は表示されません。 （これはglibcを使用している場合です）。 – fuz
（..、あなたは彼らがなど動的リンク、pthreadsを、どのように行う簡単に学びます）を理解する：
Documentation/ABI/stable/vdso（？VDSOオブジェクトが何でありますか）Documentation/vDSO/parse_vdso.c（VDSOオブジェクトのリファレンスパーサ）VDSOオブジェクトは常にLinuxでAMD64プロセスのアドレス空間にマッピングされた仮想動的共有オブジェクトです。クイックシステムコールの実装に使用できます。 VDSOオブジェクト内の機能にアクセスするには、
をアドレスを抽出します。
好奇心の高まりから、あなたの言語は、システムコールのための* C *インターフェースを使用していませんか？あなたはフリーソフトウェア実装を提供していますか？ –
@Basileフォースの仕組みを学ぶために、私はForthを書こうとしています。私は[jonesforth]（http://git.annexia.org/?p=jonesforth.git）のような既存のライブラリを持たずにアセンブリでプログラムしたいと思っています。 VDSOオブジェクトは、システムコールを実装するうえで効率的な方法です。 – fuz