Re: [uml-devel] Clearing kmalloc_ok during shutdown is broken - malloc will clear our data.

[Allan Graves <allan.graves@oracle.com>]

I'm not understanding why glibc would break the registers at will.
 From setjmp:
    /* NOTE: The machine-dependent definitions of `__sigsetjmp'
       assume that a `jmp_buf' begins with a `__jmp_buf' and that
       `__mask_was_saved' follows it.  Do not move these members
       or add others before it.  */

Seems to indicate to me that this isn't gonna change, and I'm using the 
bits/setjmp.h defines, so if they do change, the code should just follow 
along with the change.  Am I missing something?
Allan

Blaisorblade wrote:

>On Sunday 02 October 2005 03:08, Jeff Dike wrote:
>  
>
>>On Thu, Sep 29, 2005 at 04:14:02PM +0200, Blaisorblade wrote:
>>    
>>
>>>I now even found (by chance) the original mail from Allan Graves - and
>>>the changes in arch/um/include/sysdep-x86_64/ptrace.h weren't in his
>>>patch and are unrelated.
>>>Plus, I think they're also bogus (those registers exist), but I may be
>>>wrong,
>>>      
>>>
>
>  
>
>>The patch uses UPT_REG apparently for the first time.  Those registers
>>exist, but there are no defines for them in the x86_64 ptrace.h.  UPT_REG
>>is never called with any of those as its argument, so it's easy to just
>>remove those cases.
>>    
>>
>Ah, ok.
>
>  
>
>>>The only problem I see is that we need to test it on a wide glibc range -
>>>you're using an internal header detail, so glibc will break it at will.
>>>      
>>>
>
>  
>
>>Yeah, it's bad.  The other way to do it is to explictly save the registers
>>in the thread struct, which is effectively the reimplementing setjmp option
>>which you mentioned.
>>    
>>
>At least, if we save them separately from the jmpbuf_t, we can use them for 
>sysrq t, without reimplementing setjmp() and longjmp(). Not nice, wastes 24 
>bytes, but would work.
>
>I have the doubt that the location of those registers is part of the ABI, 
>(pending: find an example where I can be statically linked to glibc and 
>dynamically linked to a library dynamically linked to glibc, and must pass 
>jmpbuf_t between the two implementations)
>even if the C names aren't part of the API, so we could copy the structure.
>
>Probably, however, it's just better to test on, say, a Slackware 8.1, and hope 
>for the best and go doing a fix when things change.
>  
>


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel