From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12258 invoked by alias); 19 Dec 2011 10:31:23 -0000 Received: (qmail 12248 invoked by uid 22791); 19 Dec 2011 10:31:22 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,TW_BJ X-Spam-Check-By: sourceware.org Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Dec 2011 10:31:05 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Dec 2011 10:30:59 -0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com ([9.149.38.233]) by e06smtp12.uk.ibm.com ([192.168.101.142]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Dec 2011 10:30:56 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBJAUusJ2384088 for ; Mon, 19 Dec 2011 10:30:56 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBJAUtfN028503 for ; Mon, 19 Dec 2011 03:30:55 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id pBJAUsf4028428; Mon, 19 Dec 2011 03:30:54 -0700 Message-Id: <201112191030.pBJAUsf4028428@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 19 Dec 2011 11:30:54 +0100 Subject: Re: [patch+7.4] reread.exp 7.3->7.4 regression To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Mon, 19 Dec 2011 10:32:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker), alves.ped@gmail.com (Pedro Alves) In-Reply-To: <20111218115343.GB22534@host2.jankratochvil.net> from "Jan Kratochvil" at Dec 18, 2011 12:53:43 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 11121910-8372-0000-0000-00000124238D 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-12/txt/msg00631.txt.bz2 Jan Kratochvil wrote: > this patch should be tested on ARM, I do not yet have some ARM testing > environment (I probably could build one). I can test on ARM if you want. > This is because objfile->OBFD can change underneath registered objfile data. > > There are multiple such problems because objfile is not destroyed + recreated > on objfile reload, there was a patch for it but it has never been checked in: > [patch] Fix a reread_symbols regression by mmap > http://sourceware.org/ml/gdb-patches/2009-06/msg00606.html > http://sourceware.org/ml/gdb-patches/2009-08/msg00207.html > http://sourceware.org/ml/gdb-patches/2011-12/msg00596.html > > As I believe the patch above is not suitable for the 7.4 branch offering at > least this very ugly patch which breaks ARM functionality on rereads but it at > least does not break ARM-unrelated arches. I really think this ought to be fixed in reread_symbols; freeing the old OBFD needs to be done *after* all the callbacks to cleanup objfile data have completed. Your initial patch already moved the callbacks calls up a bit; I think it needs to be moved up even further. (There is the issue of what state the objfile is left in if any of the "error" calls is triggered, though.) In addition, we should probably call observer_notify_new_objfile so that new tables can be built up for the re-read file ... > struct arm_per_objfile > { > VEC(arm_mapping_symbol_s) **section_maps; > + > + /* A copy from OBFD. OBFD can change underneath by reread_symbols. It is > + wrong then to use arm_per_objfile but at least do not crash. */ > + unsigned int section_count; > }; That said, I guess this is OK as a workaround. However, even with the current broken code, it seems only the _free routines ever see the "wrong" OBFD. Thus I'd prefer for only the _free routines to rely on this new value ... > @@ -330,7 +334,7 @@ arm_find_mapping_symbol (CORE_ADDR memaddr, CORE_ADDR *start) > unsigned int idx; > > data = objfile_data (sec->objfile, arm_objfile_data_key); > - if (data != NULL) > + if (data != NULL && sec->the_bfd_section->index < data->section_count) > { > map = data->section_maps[sec->the_bfd_section->index]; ... and for checks in other users like this to be turned into assertions instead. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com