Re: Building on Darwin

[Tristan Gingold <gingold@adacore.com>]

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.