X$ tables are visible in X$KQFTA, for example:
SQL> select * from x$kqfta where rownum<=10; ADDR INDX INST_ID CON_ID KQFTAOBJ KQFTAVER KQFTANAM KQFTATYP KQFTAFLG KQFTARSZ KQFTACOC ---------------- ---------- ---------- ---------- ---------- ---------- ------------ ---------- ---------- ---------- ---------- 0000000016CDBF20 0 1 0 4294950912 6 X$KQFTA 4 0 80 11 0000000016CDBF70 1 1 0 4294950913 3 X$KQFVI 1 0 80 7 0000000016CDBFC0 2 1 0 4294951149 3 X$KQFVT 1 0 32 5 0000000016CDC010 3 1 0 4294950914 4 X$KQFDT 1 0 40 7 0000000016CDC060 4 1 0 4294951036 6 X$KQFCO 4 2 80 17 0000000016CDC0B0 5 1 0 4294952712 2 X$KQFOPT 1 0 24 6 0000000016CDC100 6 1 0 4294952922 3 X$KYWMPCTAB 4 0 88 12 0000000016CDC150 7 1 0 4294953009 2 X$KYWMWRCTAB 4 0 72 6 0000000016CDC1A0 8 1 0 4294952923 2 X$KYWMCLTAB 4 0 4076 7 0000000016CDC1F0 9 1 0 4294952924 5 X$KYWMNF 4 0 240 11
This information is mostly coming from the kqftab structure within the Oracle binary:
[oracle@db-21 bin]$ readelf -s oracle | grep -E -A1 -w 'Symbol|kqftab' --no-group-separator Symbol table '.dynsym' contains 225083 entries: Num: Value Size Type Bind Vis Ndx Name 224955: 0000000016cdbf20 0x18dd0 OBJECT GLOBAL DEFAULT 17 kqftab 224956: 00000000058400a0 288 FUNC GLOBAL DEFAULT 13 kole_length Symbol table '.symtab' contains 402534 entries: Num: Value Size Type Bind Vis Ndx Name 344560: 0000000016cdbf20 0x18dd0 OBJECT GLOBAL DEFAULT 17 kqftab 344561: 0000000016bc7a98 40 OBJECT GLOBAL DEFAULT 17 kqreqv
This is the actual kqftab structure:
[oracle@db-21 bin]$ objdump -s --start-address=0x0000000016cdbf20 --stop-address=$((0x0000000016cdbf20+0x18dd0)) oracle oracle: file format elf64-x86-64 Contents of section .rodata: 16cdbf20 07000000 00000000 80f52c16 00000000 ..........,..... 16cdbf30 05000000 00000000 703be816 00000000 ........p;...... 16cdbf40 04000000 00000000 50000000 00000000 ........P....... 16cdbf50 00000000 00000000 0b000000 02000000 ................ 16cdbf60 00c0ffff 06000000 00000000 00000000 ................ 16cdbf70 07000000 00000000 783be816 00000000 ........x;...... 16cdbf80 05000000 00000000 703be816 00000000 ........p;...... 16cdbf90 01000000 00000000 50000000 00000000 ........P....... 16cdbfa0 00000000 00000000 07000000 00000000 ................ 16cdbfb0 01c0ffff 03000000 00000000 00000000 ................ 16cdbfc0 07000000 00000000 803be816 00000000 .........;...... 16cdbfd0 05000000 00000000 883be816 00000000 .........;...... 16cdbfe0 01000000 00000000 20000000 00000000 ........ ....... 16cdbff0 00000000 00000000 05000000 00000000 ................ 16cdc000 edc0ffff 03000000 00000000 00000000 ................ ...
There is a visible pattern in this data. The highlighted lines contain some addresses which can be easily dereferenced:
[oracle@db-21 bin]$ for a in 162cf580 16e83b78 16e83b80 > do > objdump -s --start-address=0x$a --stop-address=$((0x$a+16)) oracle > done oracle: file format elf64-x86-64 Contents of section .rodata: 162cf580 58244b51 46544100 716b736f 7050726f X$KQFTA.qksopPro oracle: file format elf64-x86-64 Contents of section .rodata: 16e83b78 58244b51 46564900 58244b51 46565400 X$KQFVI.X$KQFVT. oracle: file format elf64-x86-64 Contents of section .rodata: 16e83b80 58244b51 46565400 6b716674 70000000 X$KQFVT.kqftp...
Not surprisingly, the order of tables is the same as in X$KQFTA. It made me think that the structure kqftab can be used to construct an output similar to X$KQFTA. That is why I wrote a simple program that reads the Oracle binary and does just that:
[oracle@db-21 ~]$ xinfo list +------------+-----+------------+-------------------------------+-----------------+---------------------------+-----+------+--------+-----+ | obj | ver | nam_ptr | nam | xstruct_nam_ptr | xstruct | typ | flg | rsz | coc | +------------+-----+------------+-------------------------------+-----------------+---------------------------+-----+------+--------+-----+ | 4294950912 | 6 | 0x16282d00 | X$KQFTA | 0x16e33810 | kqftv | 4 | 0 | 80 | 11 | | 4294950913 | 3 | 0x16e33818 | X$KQFVI | 0x16e33810 | kqftv | 1 | 0 | 80 | 7 | | 4294951149 | 3 | 0x16e33820 | X$KQFVT | 0x16e33828 | kqftp | 1 | 0 | 32 | 5 | | 4294950914 | 4 | 0x16e33830 | X$KQFDT | 0x16e33838 | kqfdt | 1 | 0 | 40 | 7 | | 4294951036 | 6 | 0x16e33840 | X$KQFCO | 0x16e33848 | kqfcc | 4 | 2 | 80 | 17 | | 4294952712 | 2 | 0x16e33850 | X$KQFOPT | 0x16e3385c | kqfopt | 1 | 0 | 24 | 6 | | 4294952922 | 3 | 0x16e33864 | X$KYWMPCTAB | 0x16e33870 | kywmpctab | 4 | 0 | 88 | 12 | | 4294953009 | 2 | 0x16e3387c | X$KYWMWRCTAB | 0x16e3388c | kywmwrctab | 4 | 0 | 72 | 6 | | 4294952923 | 2 | 0x16e33898 | X$KYWMCLTAB | 0x16e338a4 | kywmcltab | 4 | 0 | 4076 | 7 | | 4294952924 | 5 | 0x16e338b0 | X$KYWMNF | 0x16e338bc | kywmnf | 4 | 0 | 240 | 11 | ... | 4294956357 | 2 | 0x16e3a834 | X$CONSENSUS_STATS | 0x16e3a848 | kconsstats | 4 | 2 | 64 | 10 | | 4294956360 | 2 | 0x16e3a854 | X$BCAPPLY_STATS | 0x16e3a864 | kbbaStats | 4 | 2 | 260 | 16 | | 4294956225 | 2 | 0x16e3a870 | X$FSDDBFS | 0x16e3a87c | fsddbfs | 4 | 0 | 1144 | 14 | +------------+-----+------------+-------------------------------+-----------------+---------------------------+-----+------+--------+-----+ [oracle@db-21 ~]$ xinfo list 'X$KCCC*' +------------+-----+------------+---------+-----------------+---------+-----+-----+-----+-----+ | obj | ver | nam_ptr | nam | xstruct_nam_ptr | xstruct | typ | flg | rsz | coc | +------------+-----+------------+---------+-----------------+---------+-----+-----+-----+-----+ | 4294951110 | 5 | 0x16e3553c | X$KCCCF | 0x16e35544 | kcccf | 4 | 0 | 532 | 9 | | 4294951215 | 4 | 0x16e3567c | X$KCCCC | 0x16e35684 | kcccc | 5 | 6 | 48 | 14 | | 4294951392 | 5 | 0x16e35d90 | X$KCCCP | 0x16e35d98 | kctcpx | 5 | 0 | 552 | 25 | +------------+-----+------------+---------+-----------------+---------+-----+-----+-----+-----+
I also make use of other information that is stored in kqftab and add a column called xstruct to the output.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.