Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 12 Jun 2014 21:36:13 -0700 | Subject | vdso feature requests from the Go people |
| |
I was talking to some of the Go people, and they have a couple of IMO reasonable feature requests.
1. Parsing the vDSO is a PITA. What if we bundled the reference parser inside the vdso? Concretely, we could have AT_VDSO_FINDENTRY point to a function like:
void *vdso_find_entry(const char *name, const char *version)
Then things like Go and maybe even musl (and klibc?) could just call that function. And we'd never have to worry about maintaining compatibility with more and more weird vdso parsers.
Implementing this could be as simple as shoving parse_vdso.c into the vdso, although vdso2c could help and allow a really simple in-vdso implementation.
2. Go uses a segmented stack, and the vdso is quite unfriendly for segmented stack. If we can get compiler support, is there a reasonable way that we could advertise the maximum stack usage of each vdso entry point?
If we were to implement both, maybe we'd actually want to provide something like:
struct vdso_entry { unsigned long vdso_entry_struct_size; /* so we can add fields later on */ void *func; unsigned int max_stack; /* zero if not known */ };
vdso_entry *vdso_find_entry(const char *name, const char *version);
AT_VDSO_FINDENTRY would be set to &vdso_find_entry.
This shouldn't even break CRIU :)
--Andy
| |