illumos gate

While investigating other problems I tried to inspect some CTF state via mdb wanting effectively to do a ::print on something inside of it. However it fails with an error message about not being able to find the object file name.

[rm@rm ~/src/misc/projects/illumos/usr/src/lib/libc/i386/pics]$ mdb glob64.o 
> ::print struct stat
mdb: failed to look up type struct stat: unknown object file name

There are a couple different problems going on here. The first thing I noticed was that in a workspace, the following things didn't work:

[rm@rm ~/src/ws/projects/illumos/usr/src/lib/libc]$ mdb amd64/libc.so.1 -e '::print struct stat'
mdb: failed to look up type struct stat: unknown object file name
[rm@rm ~/src/ws/projects/illumos/usr/src/lib/libc]$ mdb amd64/pics/stat.o -e '::print struct stat'
mdb: failed to look up type struct stat: unknown object file name
[rm@rm ~/src/ws/projects/illumos/usr/src/lib/libc]$ mdb /usr/lib/amd64/libc.so.1 -e '::print struct stat'
{
    st_dev 
    st_ino 
    st_mode 
    st_nlink 
    st_uid 
    st_gid 
    st_rdev 
    st_size 
    st_atim {
        tv_sec 
        tv_nsec 
    }
    st_mtim {
        tv_sec 
        tv_nsec 
    }
    st_ctim {
        tv_sec 
        tv_nsec 
    }
    st_blksize 
    st_blocks 
    st_fstype 
}

Note how libc failed there along with the object file, but the system's native libc worked. Here, I was able to go through and noticed something interesting, the call to Pfindobj was failing due to the fact that the name it was given was getting truncated. This is because we managed to exceed the default 64-byte length of file_info_t that we created in Pgrab_file.

From here, I copied both the .o file and that libc.so.1 to my home directory such that we'd be within 64-bytes. However, here the mystery only deepens: now libc.so.1 in the home directory works, but the object file does not.

Let's look at the mapping information we have for both of these:

[rm@rm ~]$ mdb /usr/bin/amd64/mdb
> ::bp libproc.so.1`object_name_to_map
> ::run ./libc.so.1
mdb: warning: failed to load developer support
Loading modules: [ libc.so.1 ]
> ::print struct stat
mdb: stop at libproc.so.1`object_name_to_map
mdb: target stopped at:
libproc.so.1`object_name_to_map:pushq  %rbp
mdb: You've got symbols!
Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libproc.so.1 libc.so libavl.so.1 ]
> <rdi::print struct ps_prochandle info_valid num_files mappings map_exec map_alloc
info_valid = 0x1
num_files = 0x1
mappings = 0x51c650
map_exec = 0x51c650
map_alloc = 0x10

Now on the other hand, here's what we get for the .o.

[rm@rm ~]$ mdb /usr/bin/amd64/mdb
> ::bp libproc.so.1`object_name_to_map
> ::run ./stat.o
mdb: warning: failed to load developer support
> ::print struct stat
mdb: stop at libproc.so.1`object_name_to_map
mdb: target stopped at:
libproc.so.1`object_name_to_map:pushq  %rbp
mdb: You've got symbols!
Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libproc.so.1 ]
> <rdi::print struct ps_prochandle info_valid num_files mappings map_exec map_alloc
info_valid = 0x1
num_files = 0x1
mappings = 0
map_exec = 0
map_alloc = 0

Okay, so that's an interesting observation. For the shared object we were able to construct these headers, but we weren't able to for the object file.

This ends up being the root cause. The various CTF finding routines go through Plmid_to_ctf. It tries to take the named object and find a mapping. After which, it then goes and grabs the file_info_t for that mapping. However, if we have a relocatable object like we did above, then we don't have any mappings available. Instead, I've prototyped something which looks at idle files that have valid info, but only one file_info_t and no mapping information (which ultimately makes sense for something of type ET_REL). In this case, if we're being asked for the executable mapping (aka the primary mapping of this process handle), then we'll return the single one there.