This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, 2006-08-28 at 09:34 +0000, Wolfram Gloger wrote: > Hi, > > > I have no idea why this isn't working; but I'm trying to replace the > > glibc allocator with something else via an LD_PRELOAD. > > This should work, but it isn't easy. Maybe try the hooks first. > > > As a preliminary > > step, I've decided to do something simple: LD_PRELOAD something that > > calls straight mmap() and see if it works. > > You have: > > #define PAGE_ALIGN(x) (4096 + x & ~4095) > ^ ^ parentheses missing Algebraicly it's the same; but.... > ... > PAGE_ALIGN(size + sizeof(size_t)) // oops! .... yeah 4096 + size + (sizeof(size_t) & ~4095) won't do :) > > ... > > return addr + sizeof(size_t); > > That last one returns addresses aligned at 4, unsuitable for double > precision floats. > How large are double precision floats? 80 bits? I was wondering wtf a TB was for (TenByte, old old 286 assembly stuff). What do addresses have to round to? 16 bytes? It looks like linux rounds the stack to that on every architecture in existence. > I didn't look much further.. > > > No idea why, but 'ls' works, 'find' fails, 'xclock' works, and > > 'gcalctool' fails. Most anything fails really. I know the approach is > > crude, but it's not broken. Is there some secret trick to replacing > > glibc's allocator? > > You have to provide thread-safety for all but trivial programs. That > involves not only locking, but also pthread_atfork() hooks. > Actually the PoC just switches it with mmap() so there should be no thread safety issues. I wind up with segments looking like: [size][data...........] so I just take ptr-sizeof(size_t) on realloc/free to get the size back. The only thread issues are if multiple threads decide to realloc() or free() the same data at the same time, which will break anyway. I have a better design that does use rwlock and mutex; I don't have a pthread_atfork() function though... The expected usage is that the prepare handler acquires all mutex locks and the other two fork handlers release them. This means locking my entire allocator tree. Not a problem; I'll take a write lock on the Main Branch and lock the mutexes on each reduced lookup array for thread branches in prepare, and then release them all in the parent and do an orphan combine in the child. The order of calls to pthread_atfork() is significant. The parent and child fork handlers shall be called in the order in which they were established by calls to pthread_atfork(). The prepare fork handlers shall be called in the opposite order. Lucky, every one just adds to the list! No worries about libraries smashing me, so I'll just throw this in my constructor. > Maybe take a look at "Electric Fence". Last I checked, admittedly > a long time ago, that worked as an LD_PRELOAD shared library. > Yeah I figured this part out. I just had to start over from scratch. > Regards, > Wolfram. -- John Moser <john.r.moser@gmail.com>
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |