On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote:
>On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
>> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
>>> Hi Heiko,
>>>
>>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
>>> > On Tue, Feb 14, 202
On 08/27/18 06:11, Peter Zijlstra wrote:
> On Mon, Aug 27, 2018 at 05:26:53AM -0700, H. Peter Anvin wrote:
>
>> _THIS_IP_, however, is completely ill-defined, other than being an
>> address *somewhere* in the same global function (not even necessarily
>> the same fun
On 08/27/18 00:33, Peter Zijlstra wrote:
>
> What problem are we trying to solve? _THIS_IP_ and _RET_IP_ work fine.
> We're 'good' at dealing with text addresses, we use them for call stacks
> and all sorts. Why does this need changing?
>
_RET_IP_ works fine, with the following two caveats:
1.
On 08/26/18 12:30, H. Peter Anvin wrote:
> Here is a full-blown (user space) test program demonstrating the whole
> technique and how to use it.
>
> -hpa
Incidentally, it looks like _RET_IP_ really should be defined as:
/*
* Is there any reason whatsoever to have _RET_IP_
Here is a full-blown (user space) test program demonstrating the whole
technique and how to use it.
-hpa
#include
#include
#define _RET_IP_ ((unsigned long)__builtin_return_address(0))
#define noinline __attribute__((noinline))
#define used __attribute__((used))
/* __always_inline is d
On 08/25/18 20:16, H. Peter Anvin wrote:
> On 08/25/18 19:38, H. Peter Anvin wrote:
>>
>> If it was worthwhile it would make more sense to at least force this
>> into the rodata section with the string, something like the attached
>> file for an example; however, I hav
On 08/25/18 19:38, H. Peter Anvin wrote:
>
> If it was worthwhile it would make more sense to at least force this
> into the rodata section with the string, something like the attached
> file for an example; however, I have a hunch it doesn't matter.
>
An even nuttier vers
On 08/25/18 03:48, Helge Deller wrote:
>
> Currently alpha, s390, sparc, sh, c6x, ia64 and parisc provide an
> inline assembly function to get the current instruction pointer.
> As mentioned in an earlier thread, I personally would *prefer* if
> _THIS_IP_ would use those inline assembly instruct
,Thomas Gleixner ,Ingo Molnar
,Chris Zankel ,Max Filippov
,Arnd Bergmann
,x...@kernel.org,linux-al...@vger.kernel.org,linux-snps-arc@lists.infradead.org,linux-arm-ker...@lists.infradead.org,linux-hexa...@vger.kernel.org,linux-i...@vger.kernel.org,linux-m...@linux-mips.org,openr...@lists.librecor
wrote:
>On Sat, Mar 04, 2017 at 11:15:17AM -0800, H. Peter Anvin wrote:
>> On 03/04/17 05:05, Russell King - ARM Linux wrote:
>> >>
>> >> +static int futex_atomic_op_inuser(int encoded_op, u32 __user
>*uaddr)
>> >> +{
>> >> + int op =
com>
On March 4, 2017 1:38:05 PM PST, Stafford Horne wrote:
>On Sat, Mar 04, 2017 at 11:15:17AM -0800, H. Peter Anvin wrote:
>> On 03/04/17 05:05, Russell King - ARM Linux wrote:
>> >>
>> >> +static int futex_atomic_op_inuser(int encoded_op, u32 __user
>*ua
On 03/04/17 05:05, Russell King - ARM Linux wrote:
>>
>> +static int futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
>> +{
>> +int op = (encoded_op >> 28) & 7;
>> +int cmp = (encoded_op >> 24) & 15;
>> +int oparg = (encoded_op << 8) >> 20;
>> +int cmparg = (encoded_op <<
12 matches
Mail list logo
