From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12138 invoked by alias); 26 Aug 2009 18:25:20 -0000 Received: (qmail 12117 invoked by uid 22791); 26 Aug 2009 18:25:18 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from blu0-omc2-s26.blu0.hotmail.com (HELO blu0-omc2-s26.blu0.hotmail.com) (65.55.111.101) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Aug 2009 18:25:12 +0000 Received: from BLU0-SMTP52 ([65.55.111.72]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 11:25:10 -0700 Message-ID: Received: from gammaxp64a ([174.18.192.77]) by BLU0-SMTP52.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 11:25:09 -0700 From: "BGB" To: "Boehm, Hans" , "Andreas Krebbel" , "Andrew Haley" Cc: , , References: <20090825142045.GA14401@bart> <4A941494.8060107@redhat.com> <4A9563A7.4000209@linux.vnet.ibm.com> <238A96A773B3934685A7269CC8A8D042577AC94298@GVW0436EXB.americas.hpqcorp.net> Subject: Re: libgcj missing symbol __data_start Date: Wed, 26 Aug 2009 18:25:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00048.txt.bz2 ----- Original Message ----- From: "Boehm, Hans" To: "Andreas Krebbel" ; "Andrew Haley" Cc: ; ; Sent: Wednesday, August 26, 2009 10:41 AM Subject: RE: libgcj missing symbol __data_start > [Adding the gc mailing list, since this still applies to current gc > versions.] <-- Unfortunately, I don't think this is the right solution. If I understand correctly, DATASTART will end up as zero, which will cause the collector to start tracing at location zero, which seems unlikely to work, if the value is needed. I suspect the value isn't actually used when dl_iterate_phdr is available and the application is dynamically linked, but still ... Another popular option on other architectures is to define SEARCH_FOR_DATA_START instead of defining DATASTART to have a specific value. This creates a weak reference to __data_start. If that ends up being zero, the collector will walk the address space backwards starting at __end until an access faults. It will assume that that's the beginning of the main data segment. That might make debugging a bit harder because of the extra SIGSEGV at startup, but I still think it's a much better solution, assuming it actually works. If it doesn't, this at least needs a conspicuous FIXME comment, since it's pretty clearly doing the wrong thing. In any case, I think this should also go in the upstream source. Hans --> although not directly related, I will note that for my GC on Windows, I ended up switching to a strategy of using the ToolHelp library to iterate over the loaded modules and find their used address ranges... it also makes the GC work more reliably as well... I am not sure if something similar can be done on Linux (I have not looked into this).