From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8930 invoked by alias); 23 Dec 2011 10:32:27 -0000 Received: (qmail 8921 invoked by uid 22791); 23 Dec 2011 10:32:25 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 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; Fri, 23 Dec 2011 10:32:11 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 2658ACB1FB2; Fri, 23 Dec 2011 11:32:11 +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 jzL4Dur+s3WC; Fri, 23 Dec 2011 11:32:11 +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 14989CB1FB1; Fri, 23 Dec 2011 11:32:11 +0100 (CET) Subject: Re: Building on Darwin Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tristan Gingold In-Reply-To: <33027654.post@talk.nabble.com> Date: Fri, 23 Dec 2011 10:32:00 -0000 Cc: gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <9B7FD946-356C-44F4-8D76-2A1C53638F34@adacore.com> References: <4E000397.6030601@alum.mit.edu> <20110621042025.GD26656@adacore.com> <32D0F62F-19CA-486F-99F6-9159D23C418F@adacore.com> <0D2ED480-E928-4795-B905-049CAC3DEA05@adacore.com> <33027654.post@talk.nabble.com> To: alanandersen1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00047.txt.bz2 On Dec 23, 2011, at 6:46 AM, alanandersen1 wrote: >=20 > After fruitlessly trying to get 7.3, 7.3.1 to work for lion with Xcode 4.2 > (that seems to matter for some reason) and beating my head soundly for > several hours of trying to code sign, change permissions etc. and still > running into error after error (latest one was something about unable to > read unknown load command?) I can finally report with a sigh of relief th= at > trying the 7.4 cvs build seems to actually work. I saw on this page=20 > http://sourceware.org/gdb/wiki/GDB_7.4_Release > http://sourceware.org/gdb/wiki/GDB_7.4_Release that lion was now support= ed > and decided to give it a whirl, thanks for fixing it Tristan. You have my > deepest thanks. Thanks. There are still some issues that I won't fix for 7.4: attach/detach looks b= roken on Lion for example. Fill free to report issues. Tristan. >=20 >=20 > Tristan Gingold-2 wrote: >>=20 >>=20 >> On Nov 8, 2011, at 4:15 PM, kidoshisama wrote: >>=20 >>> I am having the same problem on my MBP, running Snow Leopard. I am no >>> longer getting the part about not being able to attach, but the >>> messages 'warning: can't find section '.const' in OSO file ...' and >>> 'warning: can't find section '__DATA.__common' in OSO file...' are >>> still there, and any backtrace has no symbol info, i.e. '#0 >>> 0x00007fff8646d196 in ?? ()'. >>>=20 >>> If one looks in machoread.c, the failure seems to be in >>> macho_add_oso_symfile(); the code is looping through >>> oso->num_sections, and for each section it gets a name and then tries >>> to load a struct. Here is the code: >>>=20 >>>=20 >>> sectname =3D (char *)oso->symbols[i]->section->name; >>> sect =3D bfd_get_section_by_name (abfd, sectname); >>>=20 >>> if (sect =3D=3D NULL) >>> { >>> warning (_("can't find section '%s' in OSO file %s"), >>> sectname, oso->name); >>> continue; >>> } >>>=20 >>> The section name is successfully read, but bfd_get_section_by_name() >>> returns NULL, apparently. >>>=20 >>> So this is as much as I know - can anyone please help me understand >>> the failure paths for this call (bfd_get_section_by_name)? Is there a >>> compilation flag being missed, or is it perhaps an incompatibility >>> with the gcc shipped wit XCode and the gdb I am building? >>>=20 >>> Any and all help would be greatly appreciated. >>=20 >> The mechanism to map OSO addresses in the executable is indeed not yet >> bullet proof. We have also seen some issues, and in particular it is >> broken on Lion. >>=20 >> I plan to do a partial rewrite for Lion and I hope to fix some weakness. >>=20 >> For such issues, the work-around (and big hammer) is to use dsymutil to >> generate a dsym file. >>=20 >> Tristan. >>=20 >>=20 >>=20 >=20 > --=20 > View this message in context: http://old.nabble.com/Building-on-Darwin-tp= 31890940p33027654.html > Sent from the Sourceware - gdb list mailing list archive at Nabble.com. >=20