共有ライブラリなしでgdb pretty-printerをフックするにはどうしたらいいですか？

Question

gdbのprettyプリンタの作成に関するすべてのドキュメントは、基本的にはこの1つのサイトです：https://sourceware.org/gdb/onlinedocs/gdb/Writing-a-Pretty_002dPrinter.html#Writing-a-Pretty_002dPrinterです。

共有ライブラリがロードされるときれいなプリンタがロードされることがわかります。

私は共有ライブラリを持っていません。私のライブラリはヘッダーのみです。私は、プログラミング言語NimのためのNimStringDesc用のきれいなプリンタを作成したいと思います。これはCにコンパイルされるので、cファイルに生成されるすべての関連部分がここにあります。

ldd nim-debug-test 
linux-vdso.so.1 (0x00007ffed8052000) 
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f4f1bf8e000) 
libc.so.6 => /usr/lib/libc.so.6 (0x00007f4f1bbed000) 
/lib64/ld-linux-x86-64.so.2 (0x00007f4f1c192000) 

をロードされるいかなるlibnimがないので、だから私は、/home/user/gdb/nim-gdb.pyのようなものを使用することはできません。

#if defined(__GNUC__) || defined(__clang__) || defined(_MSC_VER) 
# define SEQ_DECL_SIZE /* empty is correct! */ 
#else 
# define SEQ_DECL_SIZE 1000000 
#endif 
typedef char NIM_CHAR; 
typedef long long int NI64; 
typedef NI64 NI; 
struct TGenericSeq {NI len; NI reserved; }; 
struct NimStringDesc {TGenericSeq Sup; NIM_CHAR data[SEQ_DECL_SIZE]; }; 

ここでは、私が書いたテストプログラムのロードされるライブラリです。とにかく、このファイルがロードされたらどうすればいいですか？

EDIT：

NIMは、その後コンパイルさと通常のCリンカーと一緒にリンクいくつかのCファイルを作成します。これらは、NIMコンパイラによって生成されたファイルです：

~/proj/nim-debug-test/nimcache/ ls 
nim_debug_test_foobar.c stdlib_os.o   stdlib_posix.c  stdlib_strutils.o stdlib_times.c 
nim_debug_test_foobar.o stdlib_parseutils.c stdlib_posix.o  stdlib_system.c stdlib_times.o 
stdlib_os.c    stdlib_parseutils.o stdlib_strutils.c stdlib_system.o 

ときobjectfile stdlib_system.o取得のロードされたことを、私はstdlib_systemが自動的にすべてのNIMプロジェクトにインポートされていることを知っているので、私が言うことができる、それはNIMプロジェクトです。

私は1つのgdbのinitスクリプトがあります。

~/gdb/ ls 
stdlib_system-gdb.py 

をしかし、それはロードされません。これはstdlib_system-gdb.pyの内容である：ここで

class NimStringPrinter(object): 
    "Print a Nim string" 

    def __init__(self, val): 
     self.val = val 

    def to_string(self): 
     return self.val['data'] 

    def display_hint(self): 
     return 'string' 

def string_lookup_function(val): 
    lookup_tag = val.type.tag 

    if lookup_tag == None: 
     return None 

    regex = re.compile("^NimStringDesc$") 

    if regex.match(lookup_tag): 
     return StdStringPrinter(val) 

    return None 

def register_printers(objfile): 
    objfile.pretty_printers.append(string_lookup_function) 

は、いくつかのgdbの出力です：

~/proj/nim_debug_test/ gdb nim_debug_test 
GNU gdb (GDB) 7.11 
[...] 
Reading symbols from nim_debug_test...done. 
(gdb) info auto-load 
gdb-scripts: No auto-load scripts. 
guile-scripts: No auto-load scripts. 
libthread-db: No auto-loaded libthread-db. 
local-gdbinit: Local .gdbinit file was not found. 
python-scripts: No auto-load scripts. 
(gdb) show auto-load 
gdb-scripts: Auto-loading of canned sequences of commands scripts is on. 
guile-scripts: Auto-loading of Guile scripts is on. 
libthread-db: Auto-loading of inferior specific libthread_db is on. 
local-gdbinit: Auto-loading of .gdbinit script from current directory is on. 
python-scripts: Auto-loading of Python scripts is on. 
safe-path: List of directories from which it is safe to auto-load files is $debugdir:$datadir/auto-load. 
scripts-directory: List of directories from which to load auto-loaded scripts is $debugdir:$datadir/auto-load. 
(gdb) info pretty-printer 
global pretty-printers: 
    builtin 
    mpx_bound128 
(gdb) 

問題は、私は私が間違っていたかわからない、です。

Answer 1

文書は本当にobjfileと言うべきです。実行可能ファイルと共有ライブラリはまったく同じように扱われますが、共有ライブラリはdlopenになる可能性があります。その場合、後でスクリプトを呼び出すことができます。

どちらの場合でも、単に$objfile-gdb.pyという名前のファイルを作成します。そのコードはobjfileがロードされるたびに実行されます。そのスクリプトを実行するか、デバッグルートの1つをフルパス（通常はと/usr/lib/debug）に追加することができます。

のobjfileが回以上をロードされている場合に関するいくつかのinfelicitiesがあることに注意してください（あなたがrunを使用してアプリケーションを再起動し、通常ならば - dlclose - - これはまたdlopenが発生した場合、私がテストしていないdlopenシーケンス）、またはsplit debuginfoを使用する場合（別のobjfileとしてカウントされますが、同じスクリプトを使用するため）

私は、この問題を解決できるすべての実行時に変更されるカスタム__path__を持つ仮想のpythonパッケージに関するいくつかの曖昧な考えを持っています...