From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24030 invoked by alias); 15 Feb 2012 08:05:59 -0000 Received: (qmail 24017 invoked by uid 22791); 15 Feb 2012 08:05:58 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_NV X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Feb 2012 08:05:44 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 99F2A29007C; Wed, 15 Feb 2012 09:05:43 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA4BaI4AcgSb; Wed, 15 Feb 2012 09:05:43 +0100 (CET) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 87C81290007; Wed, 15 Feb 2012 09:05:43 +0100 (CET) Subject: Re: RFA: New port: ia64-hp-openvms (3/3) - ia64-vms-tdep.c Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tristan Gingold In-Reply-To: <4F3A9ED3.7090408@redhat.com> Date: Wed, 15 Feb 2012 09:14:00 -0000 Cc: "gdb-patches@sourceware.org ml" , Rupp Douglas Content-Transfer-Encoding: quoted-printable Message-Id: <3F9413FC-FB03-4970-B9FB-C628E5663826@adacore.com> References: <6AD2487F-8409-4F4E-93A6-9DB7FD195E71@adacore.com> <190A7167-B038-4EC0-82FD-815B306B4975@adacore.com> <4D8B23BF-A8D1-4698-8539-DF953219948B@adacore.com> <4F3A9ED3.7090408@redhat.com> To: Pedro Alves X-IsSubscribed: yes 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: 2012-02/txt/msg00293.txt.bz2 On Feb 14, 2012, at 6:50 PM, Pedro Alves wrote: First, thank you for your review. I am currently addressing your points. [=85] >=20 >> + info_len =3D extract_unsigned_integer (buf + 0, 4, byte_order); >> + pi->unwind_info_size =3D 8 * info_len; >> + >> + /* Read info. */ >> + pi->unwind_info =3D malloc (pi->unwind_info_size); >=20 > xmalloc Humm, do we want to exit abruptly in case of memory error ? Note that we t= est the return status. (OTOH, if malloc fails here, it is likely that the next xmalloc will too). >=20 >> + if (!pi->unwind_info) >> + return -UNW_ENOMEM; >> + >> + res =3D target_read_memory (table_addr + 8, >> + pi->unwind_info, pi->unwind_info_size); >> + if (res !=3D 0) >> + { >> + free (pi->unwind_info); >=20 > xfree >=20 >> + pi->unwind_info =3D NULL; >> + return -UNW_ENOINFO; >> + } >> + >> + /* FIXME: OSSD. */ >=20 > What's this? What's OSSD? What's left to fix? Can we fix it? OS Specific Data. That's an extension of unwinding info on VMS, that is no= t handled by libunwind. OTOH, I haven't seen them currently. I suppose they are used only in very = specific context (kernel ?) >> + >> + pi->lsda =3D table_addr + 8 + pi->unwind_info_size; >> + if (extract_unsigned_integer (buf + 4, 2, byte_order) & 3) >> + { >> + pi->lsda +=3D 8; >> + pi->handler =3D 0; /* FIXME: wrong, but who cares. */ >=20 > I don't know. But I think this needs a better comment. Sure. [=85] >=20 > Otherwise looks fine. I can't really comment on the vms or ia64 specific= s. >=20 > Just please make sure an --enable-targets=3Dall build doesn't break > unexpectedly. Will do. Thanks, Tristan.