代码之家 › 专栏 › 技术社区 › user2132190

Linux“ar”生成的索引文件在.a文件中是什么样子的?

embedded-linux arm linux

user2132190 · 技术社区 · 11 月前

我有一个由xilinx归档程序使用以下命令生成的归档文件: arm-xilinx-linux-gnueabi-ar -rs mylib.a

使用查看其内部 ar -t mylib.a 仅显示.o文件的集合。但是“s”选项应该添加索引文件以方便链接。索引文件是什么样子的?

1 回复 | 直到 11 月前

KamilCuk 11 月前

存档符号表通常命名为 / 或 // 或 __.SYMDEF 并且通常是档案中的第一个条目 https://man.freebsd.org/cgi/man.cgi?query=ar&sektion=5 部分 Special Archive Members 我来拿 libz.a 从我的系统中,我可以看到:

$ hexdump -C libz.a| head -n 60
00000000  21 3c 61 72 63 68 3e 0a  2f 20 20 20 20 20 20 20  |!<arch>./       |
00000010  20 20 20 20 20 20 20 20  30 20 20 20 20 20 20 20  |        0       |
00000020  20 20 20 20 30 20 20 20  20 20 30 20 20 20 20 20  |    0     0     |
00000030  30 20 20 20 20 20 20 20  31 36 38 34 20 20 20 20  |0       1684    |
00000040  20 20 60 0a 00 00 00 69  00 00 06 d8 00 00 06 d8  |  `....i........|
00000050  00 00 06 d8 00 00 06 d8  00 00 13 1c 00 00 13 1c  |................|
00000060  00 00 13 1c 00 00 13 1c  00 00 13 1c 00 00 13 1c  |................|
00000070  00 00 13 1c 00 00 13 1c  00 00 48 18 00 00 48 18  |..........H...H.|

第一个条目是 / 有1684个字节。然后,我可以提取索引文件并将其“显示”给您。索引文件“看起来”如下:

$ dd if=libz.a bs=1 skip=68 count=1684 status=none | hexdump -e '"%_c"'
\0*
i\0*
006330\0*
006330\0*
006330\0*
006330\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
236334\0*
236334\0*
236334\0*
3158\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0001,310\0001,310\0001;004\0001;004\0001;004\0001;004\0001;004\0001;004\0001;004\0001;004\0001t030\0001t030\0001t030\0001t030\0001t030\0001t030\0001177004\0001177004\0001177004\00012100\00012100\0001222034\0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001275,\0001275,\0001275,\0001275,\0001275,\0001275,\0001275,\0001275,\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`adler32_z\0adler32\0adler32_combine\0adler32_combine64\0get_crc_table\0crc32_z\0crc32\0crc32_combine64\0crc32_combine\0crc32_combine_gen64\0crc32_combine_gen\0crc32_combine_op\0deflateSetDictionary\0deflateGetDictionary\0deflateResetKe*
p\0deflateReset\0deflateSetHeader\0deflatePending\0deflatePrime\0deflateTune\0deflateBound\0deflate\0deflateParams\0deflateEnd\0deflateInit2_\0deflateInit_\0deflateCopy\0deflate_copyright\0inflateBackInit_\0inflateBack\0inflateBackEnd\0inflate_fast\0inflateResetKe*
p\0inflateReset\0inflateReset2\0inflateInit2_\0inflateInit_\0inflatePrime\0inflate\0inflateEnd\0inflateGetDictionary\0inflateSetDictionary\0inflateGetHeader\0inflateSync\0inflateSyncPoint\0inflateCopy\0inflateUndermine\0inflateValidate\0inflateMark\0inflateCodesUsed\0inflate_table\0inflate_copyright\0_length_code\0_dist_code\0_tr_init\0_tr_stored_block\0_tr_flush_bits\0_tr_align\0_tr_flush_block\0_tr_tal*
y\0zlibVersion\0zlibCompileFlags\0zEr*
or\0z_er*
msg\0zcal*
oc\0zcfre*
\0compres*
2\0compres*
\0compres*
Bound\0uncompres*
2\0uncompres*
\0gzclose\0gzopen\0gzopen64\0gzdopen\0gzbuf*
er\0gzrewind\0gzse*
k64\0gzse*
k\0gztel*
64\0gztel*
\0gzof*
set64\0gzof*
set\0gzeof\0gzer*
or\0gzclearer*
\0gz_er*
or\0gz_intmax\0gzread\0gzfread\0gzgetc\0gzgetc_\0gzungetc\0gzgets\0gzdirect\0gzclose_r\0gzwrite\0gzfwrite\0gzputc\0gzputs\0gzvprintf\0gzprintf\0gzflush\0gzsetparams\0gzclose_w\0*

也就是说,我觉得“看起来”不是很有用。