mjhjmtu

They seems more like a link to inode instead a link to path.
What does the readlink() mean to them, the canonical path of the inode from the calling process's root directory?
What happened when a process try to open them, will a new open file description to the inode be created?

What does the readlink() mean to them, the canonical path of the inode from the calling process's root directory?

For regular files, the link text seems related to the path the file was opened with, e.g.:

$ echo foo > abba
$ ln abba acdc
$ cat >> abba & 
[1] 12312
$ ls -l /proc/12312/fd/1
l-wx------ 1 foo users 64 Feb 19 15:19 /proc/12312/fd/1 -> /tmp/abba

Renaming that name changes the shown path:

$ mv abba qwerty
$ ls -l /proc/12312/fd/1
l-wx------ 1 foo users 64 Feb 19 15:19 /proc/12312/fd/1 -> /tmp/qwerty

As does deleting it:

$ rm qwerty
$ ls -l /proc/12312/fd/1
l-wx------ 1 foo users 64 Feb 19 15:19 /proc/12312/fd/1 -> /tmp/qwerty (deleted)

Though opening a file through the link still finds the inode in question:

$ echo testtest > /proc/12312/fd/1
$ cat acdc
testtest

For non-regular files, it shows the inode type (e.g. pipe or socket), and the inode number, which might be visible somewhere in /proc (e.g. /proc/net/tcp for TCP sockets shows the inode numbers).

What happened when a process try to open them, will a new open file description to the inode be created?

That's my impression. I think I've seen posts here on unix.SE about that, but I haven't seen any "official" documentation. The behavior is definitely that of an independent file description; I wrote a program testing that in this answer on Stackoverflow just a while ago: Duplicating file descriptor and seeking through both of them independently