Andy Lutomirski schreef op 13/06/2014 17:34:
On Thu, Jun 12, 2014 at 10:39 PM, H. Peter Anvin wrote:
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
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
Andy Lutomirski schreef op 13/06/2014 7:23:
On Thu, Jun 12, 2014 at 10:15 PM, H. Peter Anvin wrote:
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
If we were to implement both, maybe we'd actually want to provide
something like:
struct vdso_entry {
unsigned long vdso_entry_struct_size;
Andy Lutomirski schreef op 13/06/2014 7:23:
On Thu, Jun 12, 2014 at 10:15 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
If we were to implement both, maybe we'd actually want to provide
something like:
struct vdso_entry {
unsigned long
Andy Lutomirski schreef op 13/06/2014 17:34:
On Thu, Jun 12, 2014 at 10:39 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
1. Parsing the vDSO is a PITA. What if we bundled the reference
parser inside the vdso? Concretely, we could have
On 06/13/2014 08:34 AM, Andy Lutomirski wrote:
>
> I'm only aware of two implementations that work like that: glibc and
> musl. AFAIK neither one even tries to use the vdso when statically
> linked. IIRC, Bionic doesn't support the vdso at all, and Go has the
> present issue.
>
I would expect
On Thu, Jun 12, 2014 at 10:39 PM, H. Peter Anvin wrote:
> On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
>>
>> 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
On Thu, Jun 12, 2014 at 10:39 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
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
On 06/13/2014 08:34 AM, Andy Lutomirski wrote:
I'm only aware of two implementations that work like that: glibc and
musl. AFAIK neither one even tries to use the vdso when statically
linked. IIRC, Bionic doesn't support the vdso at all, and Go has the
present issue.
I would expect
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
>
> 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
On 06/12/2014 10:23 PM, Andy Lutomirski wrote:
>
> As far as I know, there's no reliable way to just read the dynsym
> table -- the thing doesn't have a specified length, which is what
> broke Go in the first place.
>
Ah yes, you're right.
>
> Parsing the ELF dynamic tables is kind of
On Thu, Jun 12, 2014 at 10:15 PM, H. Peter Anvin wrote:
> On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
>>
>> 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 06/12/2014 09:36 PM, Andy Lutomirski wrote:
>
> 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
On Thu, Jun 12, 2014 at 9:36 PM, Andy Lutomirski 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
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
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
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
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
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
On Thu, Jun 12, 2014 at 10:15 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
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 06/12/2014 10:23 PM, Andy Lutomirski wrote:
As far as I know, there's no reliable way to just read the dynsym
table -- the thing doesn't have a specified length, which is what
broke Go in the first place.
Ah yes, you're right.
Parsing the ELF dynamic tables is kind of annoyingly
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
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
20 matches
Mail list logo
