Building on Darwin

Building on Darwin

[Marty McGowan]

Hi,

     i'm trying to use gdb on my iMac
--------------
appleton:MM110605 applemcg$ ls -l /usr/bin/*cc
lrwxr-xr-x   1 root  wheel       7 Mar  4 12:49 /usr/bin/cc -> gcc-4.2
-rwxr-xr-x   1 root  wheel  287680 Oct 24  2010 /usr/bin/distcc
lrwxr-xr-x   1 root  wheel       7 Mar  4 12:49 /usr/bin/gcc -> gcc-4.2
--------------
   System Version:    Mac OS X 10.6.7 (10J869)
   Kernel Version:    Darwin 10.7.0
   Boot Volume:    hd
   Boot Mode:    Normal
   Computer Name:    appleton
   User Name:    Marty (applemcg)
   Secure Virtual Memory:    Not Enabled
   64-bit Kernel and Extensions:    No
   Time since boot:    14 days 5:50
--------------
    i've used it successfully ( a prior version ) in the past on a ~ 32K 
size C program and saw today for the first time the error message 
reported in the "Building GDB on Darwin "

    i followed the steps in "Creating a certificate",  ran the codesign  
command, and was treated with the same message:

Reading symbols from /Volumes/MM110605/src/eec/cummings...
warning: can't find section '__DATA.__common' in OSO file 
/Volumes/MM110605/src/eec/compiler.o

warning: can't find section '__DATA.__common' in OSO file 
/Volumes/MM110605/src/eec/dictionary.o

warning: can't find section '__DATA.__common' in OSO file 
/Volumes/MM110605/src/eec/options.o

warning: can't find section '__DATA.__common' in OSO file 
/Volumes/MM110605/src/eec/parserobj.o

warning: can't find section '__DATA.__common' in OSO file 
/Volumes/MM110605/src/eec/word.o
done.
(gdb) run
Starting program: /Volumes/MM110605/src/eec/cummings
Unable to find Mach task port for process-id 95355: (os/kern) failure (0x5).
  (please check gdb is codesigned - see taskgated(8))
(gdb)


     I included the "cant find section ... " messages as I don't recall 
seeing them in times past, and to offer any kind of clue.

     I did have to go to the trouble of resetting my login keys in the 
OS X, as i really have little idea of what's happening.  i do get the 
RSA, public key algorithm, but frankly what a certificate represents and 
who is giving whom what and why escapes my ken.

    in the btw department; i tried this repeatedly.   in the first 
instance, i created a 2K Certificates.p12 file (before resetting the 
password, but i was successfully able to import into the System keychain 
as recommended.  that failed as well.   then repeating the experiment,  
but this time with (continue)^ nth, i received "unknown error" when the 
certificate was being created.  in this pass i offered no identity to 
the certificate assistant.   repeating a 4th or fifth time, but 
supplying identity, i was able to export a *.pem file, which is just the 
ascii email attachment.  needless to say it was not effective.

    is there a cookbook for this procedure?   do i need to rebuild gcc?

  Thanks,


-- 
-=*-+ Marty McGowan http://martymcgowan.tiddlyspace.com

Re: Building on Darwin

[Joel Brobecker]

> (gdb) run
> Starting program: /Volumes/MM110605/src/eec/cummings
> Unable to find Mach task port for process-id 95355: (os/kern) failure (0x5).
>  (please check gdb is codesigned - see taskgated(8))

You either have to codesign gdb (see taskgated(8)), or another option
is to change gdb's permissions using 'chgrp procmod' + 'chmod g+s'.

-- 
Joel

Re: Building on Darwin

[Tristan Gingold]

On Jun 21, 2011, at 6:20 AM, Joel Brobecker wrote:

>> (gdb) run
>> Starting program: /Volumes/MM110605/src/eec/cummings
>> Unable to find Mach task port for process-id 95355: (os/kern) failure (0x5).
>> (please check gdb is codesigned - see taskgated(8))
> 
> You either have to codesign gdb (see taskgated(8)), or another option
> is to change gdb's permissions using 'chgrp procmod' + 'chmod g+s'.

Also, read:

http://sourceware.org/gdb/wiki/BuildingOnDarwin

Re: Building on Darwin

[kidoshisama]

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.

Thanks,

Keith

Re: Building on Darwin

[Tristan Gingold]

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.

Re: Building on Darwin

[alanandersen1]

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.


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.

Re: Building on Darwin

[Tristan Gingold]

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.
>