From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25733 invoked by alias); 3 Jun 2003 14:39:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25637 invoked from network); 3 Jun 2003 14:39:08 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by sources.redhat.com with SMTP; 3 Jun 2003 14:39:08 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19NCu7-0002U7-00 for ; Tue, 03 Jun 2003 16:36:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gdb-patches@sources.redhat.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19NCtq-0002Su-00 for ; Tue, 03 Jun 2003 16:36:30 +0200 From: Raoul Gough Subject: Re: [RFA] Add shared object relocation tests Date: Tue, 03 Jun 2003 14:39:00 -0000 Message-ID: References: <20030603130744.GB13577@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.4 (windows-nt) Cancel-Lock: sha1:mmMoanZRS3+KbymmED/dRJ4DRw4= X-SW-Source: 2003-06/txt/msg00124.txt.bz2 Daniel Jacobowitz writes: > On Tue, Jun 03, 2003 at 11:14:44AM +0100, Raoul Gough wrote: [snip] >> Should I go ahead and add the new files? > > First of all, even new files get a changelog entry. It will go in > gdb/testeuite/ChangeLog. Thanks for pointing this out - I'd forgotten this entirely. The src/gdb/testsuite/ChangeLog entry would be: 2003-06-03 Raoul Gough * gdb.base/shreloc.exp: New file, check symbols obtained from shared objects that required relocation at load time (gdb PR/1132). * gdb.base/shreloc.c, gdb.base/shreloc1.c, gdb.base/shreloc2.c: as above, part of the shared object relocation test. > >> foreach module [list "shreloc" "shreloc1" "shreloc2"] { >> if {[gdb_compile "${srcdir}/${subdir}/${module}.c" "${workdir}/${module}.o" object {debug}] != ""} { >> gdb_suppress_entire_file "${module}.c compile failed, so all tests in this file will automatically fail." >> return -1 >> } >> } [snip similar cases] > > Please just use return, not gdb_suppress_entire_file. In particular, > using both causes the _next_ test to fail, I think. Hmmm.... gdb_suppress_entire_file seems to be the usual response to testcase compilation failures, so it would probably make more sense to remove the return statement instead. I don't really know what the pros and cons are in this case - is there some reason to prefer the return option (what about logging the error in that case?) > > Other than those two details, this is OK. Give other people a day or > so to comment and then check it in. Thanks for the feedback, and I'll hold off for a couple of days on the update. -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta