On Thu, Jun 12, 2014 at 9:36 PM, Andy Lutomirski <l...@amacapital.net> wrote: > 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 :) >
Alternatively we could just assign each entry a stable index and supply a table: AT_VDSO_ENTRIES would point to: struct { unsigned long nentries; vdso_entry entries[]; } Simpler, faster, but less flexible. This version wouldn't even need help from vdso2c. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/