From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17665 invoked by alias); 6 Dec 2013 17:22:15 -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 17654 invoked by uid 89); 6 Dec 2013 17:22:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pd0-f173.google.com Received: from Unknown (HELO mail-pd0-f173.google.com) (209.85.192.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 06 Dec 2013 17:22:14 +0000 Received: by mail-pd0-f173.google.com with SMTP id p10so1360808pdj.32 for ; Fri, 06 Dec 2013 09:22:06 -0800 (PST) X-Received: by 10.66.235.106 with SMTP id ul10mr5437641pac.19.1386350526332; Fri, 06 Dec 2013 09:22:06 -0800 (PST) Received: from sspiff.sspiff.org.gmail.com (173-13-178-50-sfba.hfc.comcastbusiness.net. [173.13.178.50]) by mx.google.com with ESMTPSA id qv8sm30925521pbc.31.2013.12.06.09.22.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2013 09:22:05 -0800 (PST) From: Doug Evans To: Phil Muldoon Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v1 03/13] script language API for GDB: python.[ch] changes References: <52a1662d.a601430a.7cf1.61b3@mx.google.com> <52A1C475.4010901@redhat.com> Date: Fri, 06 Dec 2013 17:22:00 -0000 In-Reply-To: <52A1C475.4010901@redhat.com> (Phil Muldoon's message of "Fri, 06 Dec 2013 12:35:01 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00254.txt.bz2 Phil Muldoon writes: >> + >> +extern int gdbpy_auto_load_enabled (const struct script_language_defn *); >> + >> +/* script_language_ops "methods". */ >> + >> +extern int gdbpy_apply_val_pretty_printer >> + (const struct script_language_defn *, >> + struct type *type, const gdb_byte *valaddr, >> + int embedded_offset, CORE_ADDR address, >> + struct ui_file *stream, int recurse, >> + const struct value *val, >> + const struct value_print_options *options, >> + const struct language_defn *language); >> +extern enum script_bt_status gdbpy_apply_frame_filter >> + (const struct script_language_defn *, >> + struct frame_info *frame, int flags, enum script_frame_args args_type, >> + struct ui_out *out, int frame_low, int frame_high); >> +extern void gdbpy_preserve_values (const struct script_language_defn *, >> + struct objfile *objfile, >> + htab_t copied_types); >> +extern enum scr_bp_stop gdbpy_breakpoint_cond_says_stop >> + (const struct script_language_defn *, struct breakpoint *); >> +extern int gdbpy_breakpoint_has_cond (const struct script_language_defn *, >> + struct breakpoint *b); > > I did not ask in the previous patch, but why could not these functions > have been kept in Python? Not sure I understand the question. Can you elaborate? >> >> +/* Some code (e.g., MI) wants to know if a particular scripting language >> + successfully initialized. >> + Return non-zero if Python scripting successfully initialized. */ >> + >> +int >> +script_lang_python_initialized (void) >> +{ >> + if (script_language_python.ops != NULL) >> + return script_language_python.ops->initialized (&script_language_python); >> + return 0; >> +} >> + > > I missed the convention here, but I thought that methods exported to > the ops struct had a gdbpy_ prefix? This one isn't exported through the ops struct. OTOH, as noted in an earlier email, a better way to go would be a general function that took a script_lang enum as an argument.