This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Building on Darwin
- From: Tristan Gingold <gingold at adacore dot com>
- To: alanandersen1 <alanderr at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Fri, 23 Dec 2011 11:32:09 +0100
- Subject: Re: Building on Darwin
- References: <4E000397.6030601@alum.mit.edu> <20110621042025.GD26656@adacore.com> <32D0F62F-19CA-486F-99F6-9159D23C418F@adacore.com> <CAB+SFK1dbFyPWfPKYbpUqum9hY7ND=ydqdJTEe3OM8eFz+V_Ow@mail.gmail.com> <0D2ED480-E928-4795-B905-049CAC3DEA05@adacore.com> <33027654.post@talk.nabble.com>
On Dec 23, 2011, at 6:46 AM, alanandersen1 wrote:
>
> 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 that
> trying the 7.4 cvs build seems to actually work. I saw on this page
> http://sourceware.org/gdb/wiki/GDB_7.4_Release
> http://sourceware.org/gdb/wiki/GDB_7.4_Release that lion was now supported
> 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 broken on Lion for example.
Fill free to report issues.
Tristan.
>
>
> Tristan Gingold-2 wrote:
>>
>>
>> On Nov 8, 2011, at 4:15 PM, kidoshisama wrote:
>>
>>> 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 ?? ()'.
>>>
>>> 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:
>>>
>>>
>>> sectname = (char *)oso->symbols[i]->section->name;
>>> sect = bfd_get_section_by_name (abfd, sectname);
>>>
>>> if (sect == NULL)
>>> {
>>> warning (_("can't find section '%s' in OSO file %s"),
>>> sectname, oso->name);
>>> continue;
>>> }
>>>
>>> The section name is successfully read, but bfd_get_section_by_name()
>>> returns NULL, apparently.
>>>
>>> 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?
>>>
>>> Any and all help would be greatly appreciated.
>>
>> 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.
>>
>> I plan to do a partial rewrite for Lion and I hope to fix some weakness.
>>
>> For such issues, the work-around (and big hammer) is to use dsymutil to
>> generate a dsym file.
>>
>> Tristan.
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Building-on-Darwin-tp31890940p33027654.html
> Sent from the Sourceware - gdb list mailing list archive at Nabble.com.
>