On Thu, Nov 15, 2012 at 9:49 AM, Xinliang David Li wrote:
> I am sensing some optimization here :) Is it really important to
> collect the full stack trace for the allocation context?
Not important if you want to *find* a bug.
Deadly important if you want to *analyze* the bug.
The free() traces
I am sensing some optimization here :) Is it really important to
collect the full stack trace for the allocation context? You care
about actual site where the allocation happens -- which might usually
be the calls to the malloc like wrappers. The distance from there to
the leaf should not he too fa
On Thu, Nov 15, 2012 at 9:25 AM, Dmitry Vyukov wrote:
> On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek wrote:
>> On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
>>> +dvyukov, +glider, +samsonov
>>>
>>> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
>>>
On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek wrote:
> On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
>> +dvyukov, +glider, +samsonov
>>
>> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
>> Alexey may submit the patch upstream.
>> Please make sure to
On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
> +dvyukov, +glider, +samsonov
>
> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
> Alexey may submit the patch upstream.
> Please make sure to comment the reason for using a separate typedef.
>
> We need
On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
> +dvyukov, +glider, +samsonov
>
> Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
> Alexey may submit the patch upstream.
> Please make sure to comment the reason for using a separate typedef.
Here is the
+dvyukov, +glider, +samsonov
Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
Alexey may submit the patch upstream.
Please make sure to comment the reason for using a separate typedef.
We need our custom unwinder based on frame pointers to remain the
default choice on x86[_64]
On Thu, Nov 15, 2012 at 1:26 AM, Jakub Jelinek wrote:
> On Wed, Nov 14, 2012 at 07:51:05PM -0800, H.J. Lu wrote:
>> X32 uses 32-bit pointer in software. But its hardware pointer is
>> 64-bit. We must use hardware pointer to unwind frames. This patch
>> adds uhwptr for hardware pointer and uses
On Wed, Nov 14, 2012 at 07:51:05PM -0800, H.J. Lu wrote:
> X32 uses 32-bit pointer in software. But its hardware pointer is
> 64-bit. We must use hardware pointer to unwind frames. This patch
> adds uhwptr for hardware pointer and uses it to unwind stack frames.
> Tested on Linux/x32, Linux/x86-
On Wed, Nov 14, 2012 at 7:51 PM, H.J. Lu wrote:
> Hi,
>
> X32 uses 32-bit pointer in software. But its hardware pointer is
> 64-bit. We must use hardware pointer to unwind frames. This patch
> adds uhwptr for hardware pointer and uses it to unwind stack frames.
> Tested on Linux/x32, Linux/x86-
Hi,
X32 uses 32-bit pointer in software. But its hardware pointer is
64-bit. We must use hardware pointer to unwind frames. This patch
adds uhwptr for hardware pointer and uses it to unwind stack frames.
Tested on Linux/x32, Linux/x86-64 and Linux/ia32. Please review it
for upstream.
Thanks.
11 matches
Mail list logo
