From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9661 invoked by alias); 11 Mar 2011 22:17:20 -0000 Received: (qmail 9653 invoked by uid 22791); 11 Mar 2011 22:17:19 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Mar 2011 22:17:14 +0000 Received: (qmail 21360 invoked from network); 11 Mar 2011 22:17:12 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Mar 2011 22:17:12 -0000 Date: Fri, 11 Mar 2011 22:35:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org, rearnsha@arm.com, matthew.gretton-dann@arm.com Subject: Re: [rfc/rfa] Use ARM exception tables as GDB unwinder Message-ID: <20110311221709.GZ25422@caradoc.them.org> References: <20101212042135.GG11377@caradoc.them.org> <201103091843.p29Ih4l9002682@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103091843.p29Ih4l9002682@d06av02.portsmouth.uk.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00685.txt.bz2 On Wed, Mar 09, 2011 at 07:43:04PM +0100, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > On Wed, Dec 01, 2010 at 05:45:31PM +0100, Ulrich Weigand wrote: > > > Hmm, looking at DO_CALL a bit more I think this can actually be handled > > > inline just fine: > > > > > > #define DO_CALL(syscall_name, args) \ > > > DOARGS_##args; \ > > > mov ip, r7; \ > > > cfi_register (r7, ip); \ > > > ldr r7, =SYS_ify (syscall_name); \ > > > swi 0x0; \ > > > mov r7, ip; \ > > > cfi_restore (r7); \ > > > UNDOARGS_##args > > > > > > Note the calls to DOARGS_... / UNDOARGS_..., which actually save and > > > restore registers on the stack anyway (just not r7). Why not simply > > > have (a variant) of [UN]DOARGS_... save r7 to the stack, and then > > > provide both correct CFI and ARM unwind records for it? [ Saving > > > to IP would then be no longer necessary. ] > > > > > > Am I missing something here? > > > > I don't think you are missing anything, except a couple of cycles. > > > > We save r7 in ip because it ought to be faster loading and storing it > > on the stack. But we already take the position that the system call > > overhead is substantial compared to DO_CALL... so the extra two memory > > ops do not seem like a huge loss to me, especially if we can save on > > code size. > > I finally got around to continue working on this. The patch below > implements this approach. However, this uncovered one rather fundamental > problem: when implementing the vfork system call, the syscall stub > must *not* put anything on the stack or else things will break due to > the peculiar semantics of vfork: > > The system will return to execute solely the child at first, until such > time as the child calls exec; and in the meantime, the child will share > the parent's address space. Now if vfork pushed something on the stack, > the child will pop that value, and go on to overwrite that stack location > with other stuff. Once the parent later gets to run as well, it will > restore a corrupted value into r7 ... > > I'm not quite sure if there is a way around this ... Any suggestions > would be appreciated. Hmm, I wonder if that's why I did it this way before. Can we use a different technique to implement vfork than for other system calls? I don't see a reason they all need to be the same. > As Andreas notes, DOARGS is called with a 0 argument. However, I'm > wondering if there isn't a bug anyway: > > __##syscall_name##_nocancel: \ > .cfi_sections .debug_frame; \ > cfi_startproc; \ > DO_CALL (syscall_name, args); \ > PSEUDO_RET; \ > cfi_endproc; \ > .size __##syscall_name##_nocancel,.-__##syscall_name##_nocancel; \ > > Shouldn't there be a > cmn r0, $4096; > in between the DO_CALL and the PSEUDO_RET? It does look that way. > Also, some of the code in the linuxthreads/ directories seems to be broken, > but I'm wondering why those are still there in the first place; linuxthreads > support has been removed from glibc a long time ago, hasn't it? Yes. Those files should just be removed. -- Daniel Jacobowitz Mentor Graphics