From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>, "Carlos O'Donell" <carlos@redhat.com>
Cc: gnu-gabi@sourceware.org
Subject: Re: RFC: ABI support for special memory area
Date: Sun, 01 Jan 2017 00:00:00 -0000 [thread overview]
Message-ID: <7eda6605-ff47-a829-8608-f3f40b2c0160@redhat.com> (raw)
In-Reply-To: <CAMe9rOoApoxUSe-LqScqm0+_NmyNwUMK0kU9WV5whMtz+dRryw@mail.gmail.com>
On 02/28/2017 06:03 PM, H.J. Lu wrote:
> On Tue, Feb 28, 2017 at 8:19 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 02/23/2017 09:59 PM, H.J. Lu wrote:
>>>> Why does it run _after_ all shared objects and the executable file are loaded?
>>>
>>> Since __gnu_mbind_setup may call any external functions, it can only
>>> be done after everything is loaded and relocated.
>>
>> Who defines this function?
>
> Platform vendor with special memory support should provide such function.
>
>> Where is it implemented?
>
> We are working on libmbind to implement it.
That's backwards. Either we need to merge libmbind in to glibc, or this
should be something provided by the kernel vDSO.
We certainly don't want to repeat the mistake with the unwinder and
libgcc_s.
>> Why can't this be run in a constructor? Is that too late?
>
> We can use MCDRAM for dynamically allocated memory with
> memkind. We are looking for a user-friendly way to use MCDRAM
> for normal data variables.
Is it really necessary to avoid the pointer indirection?
Thanks,
Florian
next prev parent reply other threads:[~2017-03-01 16:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-01 0:00 H.J. Lu
2017-01-01 0:00 ` Carlos O'Donell
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Carlos O'Donell
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Florian Weimer [this message]
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Carlos O'Donell
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Suprateeka R Hegde
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Florian Weimer
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Florian Weimer
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Florian Weimer
2017-01-01 0:00 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7eda6605-ff47-a829-8608-f3f40b2c0160@redhat.com \
--to=fweimer@redhat.com \
--cc=carlos@redhat.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).