On 2018-08-02 4:31 PM, Nick Desaulniers wrote:
If I understand your point correctly, is it that you're saying that
_THIS_IP_ should be implemented in terms of inline assembly (as in
what current_text_addr() is currently)? If that's what you mean and
I'm understanding correctly, my point is that we should be preferring
the generic C implementation as that's what's being used in most
places currently, so if it was broken you'd likely already know about
it. Unless unwinding is truly broken by the additional label, I don't
think we need an inline assembly implementation of current_text_addr()
for parisc (or any arch for that matter). If we do, then it can be
localized to the parisc unwinding code, that way it can be
consolidated everywhere else for every other arch.
The label breaks the unwind data, not the unwind code. So, localizing
the use of
current_text_addr() to the parisc unwind code doesn't help.
Personally, I prefer the implementation of current_text_addr() because:
1) The generated code is smaller, and
2) it doesn't introduce any unnecessary labels into the text.
As noted, these labels can cause issues with unwinding.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html