From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6264 invoked by alias); 4 Nov 2014 14:26:25 -0000 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 Received: (qmail 6253 invoked by uid 89); 4 Nov 2014 14:26:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f43.google.com Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 04 Nov 2014 14:26:23 +0000 Received: by mail-oi0-f43.google.com with SMTP id e131so10391356oig.2 for ; Tue, 04 Nov 2014 06:26:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kLqjoEtX3ubvUHQwwMfW7KSB7O6AY5V1oEg7TSmFatI=; b=HaxlLKh/5DpU6HMPDY+AHN/LNaJV+3x0GkBq5zL4ukdvOlO6+vPKKbQaMED/kxt9PR aZxyOIkcJpAt8LCydG31E9dDfj4c/MJQhWWEiaS+H+oSHzMGq4MH5xudA5qjZKJMSkO6 dHHNbYio3uxjRIXigaBCoCaxmw63LbfXqoTEDpd838dvst0pXSmvCUocTYuULMlUwuVl 1dp6gHcp3xBR9cFvbSDiO+pB+gvMijamkdNfoVfF4hM0ljMTyKHPzp81B4rBRNZiX0yv Kfbwx5CwvWQE4DhfKdc4GdStdL7XIQglEDqWFxVvSc280syIWVGBNB0FbgBzWSJ1pdaZ CJzw== X-Gm-Message-State: ALoCoQkdvGSxLYvJA+THY3M2Mlat3ygIcIrmj1Yxb3oXjpe4JARv7ZM1kcZIreKoKLzAcyROXCfv MIME-Version: 1.0 X-Received: by 10.202.207.207 with SMTP id f198mr40143276oig.46.1415111181519; Tue, 04 Nov 2014 06:26:21 -0800 (PST) Received: by 10.202.197.13 with HTTP; Tue, 4 Nov 2014 06:26:21 -0800 (PST) In-Reply-To: <201411041338.sA4DcY9L011619@d06av02.portsmouth.uk.ibm.com> References: <201411041338.sA4DcY9L011619@d06av02.portsmouth.uk.ibm.com> Date: Tue, 04 Nov 2014 14:26:00 -0000 Message-ID: Subject: Re: [PATCH v4] Make chained function calls in expressions work From: Siva Chandra To: Ulrich Weigand Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00062.txt.bz2 On Tue, Nov 4, 2014 at 5:38 AM, Ulrich Weigand wrote: > Yes, having an additional flag in struct expression would fix the safety > issue. Moving initialization to evalute_subexp if *pos == 0 would then > no longer be safety issue, but simply enabling use of temporaries in more > cases. Since I have my code already setup in this fashion, I would prefer to go this route unless you see an advantage of going with the solution you suggest below. > The other option I've been thinking of would be to move the whole handling > of temporaries to infcall.c, by providing two functions there, e.g. called: > > infcall_enable_on_stack_temporaries () > infcall_cleanup_on_stack_temporaries () > > These would use a new field in the inferior_thread () thread struct to > store the vector of currently in use on-stack temporaries. Any call to > call_function_by_hand after infcall_enable_on_stack_temporaries (and > before infcall_cleanup_on_stack_temporaries) on the same thread would > be allowed to use temporaries. [ There could be sanity checks like > having call_function_by_hand verify that the current SP still equals > the thread SP at the time infcall_enable_on_stack_temporaries was > called. Also, infrun could assert that a thread that has temporaries > in use must only ever run during is_infcall, to catch missing cleanup > calls. ] >ReadStringAndDumpToStream (ReadStringAndDumpToStreamOptions options) > The only thing evaluate_expression would then need to do is to call > infcall_enable_on_stack_temporaries and install a cleanup calling > infcall_cleanup_on_stack_temporaries. [...] > So I'm thinking of the following sequence of events: > > - We call the first call_function_by_hand with a current sp value SP > (no pre-existing temporaries at this point). > - We have to reserve the red zone, setting sp e.g. to SP - 256. > - We now allocate a temporary, taking up e.g. SP - 256 .. SP - 512. > - First call_function_by_hand returns. > - We get a second call_function_by_hand call. > - Now we have a temporary on the stack from SP - 256 .. SP - 512, > so skip_current_expression_stack skips down to SP - 512. > - *Now* code allocates the red zone again, setting SP to SP - 768. > Even though this is unnecessary; the red zone is actually already > there in the range SP ... SP - 256. > > Bascially, adding a red zone at any point other the original SP isget_xmethod_arg_types > useless, since the only point of the red zone is to protect data that > the original inferior code might have written to its stack immediately > below the original SP. Oops! Sorry, I misread my own code. You are right and I will fix it. > You mean "Any two or more lines in code should be wrapped in braces, even > if they are comments, as they look like separate statements"? I don't think > this is intended to apply to cases like the above where a single statement > just had to split into multiple lines since it doesn't fit into one. > This case will never "look like separate statements". In any case, all > the existing precedent in GDB does not have extra braces in that case. Sorry for picking this. I point out because I was asked to put braces for cases like this in the past. Example: extension.c:get_xmethod_arg_types.