Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v10)

* Mathieu Desnoyers:

----- On Jun 12, 2019, at 4:00 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

quoted

----- On Jun 10, 2019, at 4:43 PM, carlos carlos@redhat.com wrote:

quoted

On 6/6/19 7:57 AM, Florian Weimer wrote:

quoted

Let me ask the key question again: Does it matter if code observes the
rseq area first without kernel support, and then with kernel support?
If we don't expect any problems immediately, we do not need to worry
much about the constructor ordering right now.  I expect that over time,
fixing this properly will become easier.

I just wanted to chime in and say that splitting this into:

* Ownership (__rseq_handled)

* Initialization (__rseq_abi)

Makes sense to me.

I agree we need an answer to this question of ownership but not yet
initialized, to owned and initialized.

I like the idea of having __rseq_handled in ld.so.

Very good, so I'll implement this approach. Sorry for the delayed
feedback, I am traveling this week.

I had issues with cases where application or LD_PRELOAD library also
define the __rseq_handled symbol. They appear not to see the same
address as the one initialized by ld.so.

What exactly did you do?  How did you determine the addresses?  How is
__rseq_handled defined in ld.so?

Thanks,
Florian