On Sat, Nov 08, 2014 at 07:46:08PM +0100, Maxime Villard wrote:
> Le 08/11/2014 19:08, Michael van Elst a écrit :
> >As a side effect, it removed the debugging features of malloc/free.
>
> As well as it allowed many bugs.
I doubt that it allowed many bugs. It made code slightly more complex,
but
Le 08/11/2014 23:28, Jean-Yves Migeon a écrit :
Le 08/11/2014 19:43, Maxime Villard a écrit :
Le 08/11/2014 18:06, Jean-Yves Migeon a écrit :
I agree that the size not being tracked by the allocator (well, it is,
but the API is ill-designed in this regard) leads to great bugs.
Two things come
On Nov 9, 11:52am, Masao Uebayashi wrote:
} On Sun, Nov 9, 2014 at 11:22 AM, John Nemeth wrote:
} > The question wasn't simply about "ld -r" stuff. It was about
} > the entire program of config(1) changes, linking changes, module(9)
} > changes, etc. There's an awful lot of stuff happening
On Sun, Nov 09, 2014 at 11:59:11AM +0100, Maxime Villard wrote:
> Help debugging? Tagging allocations?
>
> Look at sys/sys/malloc.h:
>
> #define malloc(size, type, flags) kern_malloc(size, flags)
>
> The tag is not even compiled in. Thus it can hardly help debugging
> anything.
>
>
Date:Sun, 09 Nov 2014 09:06:40 +0100
From:Maxime Villard
Message-ID: <545f2090.4000...@m00nbsd.net>
| My point is:
| - KMEM_SIZE is only enabled on DIAGNOSTIC.
Which makes sense if we're assuming the point of DIAGNOSTIC is to help
track kernel programming erro
Do I understand this correctly?
o .eh_frame is GNU extension debug info to unwind stack [1]
o .eh_frame is generated by GCC/LLVM [2]
o Some code under src/sys/ reference it, but not finished & hooked to any
kernel functionality (ddb(4)?)
o .eh_frame in kernel is not used yet, and safely removed
Ok, I'm fine with this; what you say partly convinces me:
Le 09/11/2014 12:43, Robert Elz a écrit :
Date:Sun, 09 Nov 2014 09:06:40 +0100
From:Maxime Villard
Message-ID: <545f2090.4000...@m00nbsd.net>
| My point is:
| - KMEM_SIZE is only enabled on DIAGN
Maxime Villard wrote:
> Hi,
> there's something terribly sad with the kmem API: kmem_free takes
> a size argument. It has I think two major drawbacks:
>
> <...>
>
> Here is a patch which implements kmem_valloc.
>
> Comments?
I object to such addition; others already explained various aspects o
Le 09/11/2014 09:43, Michael van Elst a écrit :
On Sat, Nov 08, 2014 at 07:46:08PM +0100, Maxime Villard wrote:
Le 08/11/2014 19:08, Michael van Elst a écrit :
As a side effect, it removed the debugging features of malloc/free.
As well as it allowed many bugs.
I doubt that it allowed many b
Le 09/11/2014 14:00, Maxime Villard a écrit :
After all, kmem_intr_zalloc is not needed since the caller can simply do
ptr = kmem_intr_alloc(...);
memset(ptr, 0, ...);
That's because kmem_intr_zalloc() is naive. It could also allocate a
page from pools where the page has been previou
On Sun, Nov 09, 2014 at 09:26:45PM +0900, Masao Uebayashi wrote:
> o .eh_frame is GNU extension debug info to unwind stack [1]
No.
> o .eh_frame is generated by GCC/LLVM [2]
Yes.
> o Some code under src/sys/ reference it, but not finished & hooked to any
> kernel functionality (ddb(4)?)
Yes.
On Mon, Nov 10, 2014 at 1:24 AM, Joerg Sonnenberger
wrote:
> On Sun, Nov 09, 2014 at 09:26:45PM +0900, Masao Uebayashi wrote:
>> o .eh_frame is GNU extension debug info to unwind stack [1]
>
> No.
Ian Lance Taylor said that it is similar to DWARF .debug_frame, but different.
>> o .eh_frame is ge
Le 09/11/2014 09:06, Maxime Villard a écrit :
Le 08/11/2014 23:28, Jean-Yves Migeon a écrit :
My suggestion was to enable the size setters/getters by default, and
possibly #ifdef part of the code that would be deemed unsuitable for
!diagnostic kernels.
Yes, but still, what's the point of givin
On Mon, Nov 10, 2014 at 01:40:59AM +0900, Masao Uebayashi wrote:
> On Mon, Nov 10, 2014 at 1:24 AM, Joerg Sonnenberger
> wrote:
> > On Sun, Nov 09, 2014 at 09:26:45PM +0900, Masao Uebayashi wrote:
> >> o .eh_frame is GNU extension debug info to unwind stack [1]
> >
> > No.
>
> Ian Lance Taylor sa
You might find this useful:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-October/005546.html
Several notes:
- while eh_frame is meant to be the minimum information needed to
unwind function calls, the desire to unwind through C code and signals
from C++ means that most systems ship with the
On Mon, Nov 10, 2014 at 4:02 AM, Andrew Cagney wrote:
> You might find this useful:
>
> http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-October/005546.html
>
> Several notes:
>
> - while eh_frame is meant to be the minimum information needed to
> unwind function calls, the desire to unwind throug
On Mon, Nov 10, 2014 at 2:12 AM, Joerg Sonnenberger
wrote:
> On Mon, Nov 10, 2014 at 01:40:59AM +0900, Masao Uebayashi wrote:
>> On Mon, Nov 10, 2014 at 1:24 AM, Joerg Sonnenberger
>> wrote:
>> > On Sun, Nov 09, 2014 at 09:26:45PM +0900, Masao Uebayashi wrote:
>> >> o .eh_frame is GNU extension d
17 matches
Mail list logo
