* Building on Darwin
@ 2011-06-21 2:36 Marty McGowan
2011-06-21 4:20 ` Joel Brobecker
0 siblings, 1 reply; 7+ messages in thread
From: Marty McGowan @ 2011-06-21 2:36 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building on Darwin
2011-06-21 2:36 Building on Darwin Marty McGowan
@ 2011-06-21 4:20 ` Joel Brobecker
2011-06-21 7:37 ` Tristan Gingold
0 siblings, 1 reply; 7+ messages in thread
From: Joel Brobecker @ 2011-06-21 4:20 UTC (permalink / raw)
To: Marty McGowan; +Cc: gdb
> (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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building on Darwin
2011-06-21 4:20 ` Joel Brobecker
@ 2011-06-21 7:37 ` Tristan Gingold
2011-11-08 15:15 ` kidoshisama
0 siblings, 1 reply; 7+ messages in thread
From: Tristan Gingold @ 2011-06-21 7:37 UTC (permalink / raw)
To: Marty McGowan; +Cc: gdb, Joel Brobecker
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building on Darwin
2011-06-21 7:37 ` Tristan Gingold
@ 2011-11-08 15:15 ` kidoshisama
2011-11-09 7:51 ` Tristan Gingold
0 siblings, 1 reply; 7+ messages in thread
From: kidoshisama @ 2011-11-08 15:15 UTC (permalink / raw)
To: Tristan Gingold; +Cc: Marty McGowan, gdb, Joel Brobecker
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building on Darwin
2011-11-08 15:15 ` kidoshisama
@ 2011-11-09 7:51 ` Tristan Gingold
2011-12-23 5:46 ` alanandersen1
0 siblings, 1 reply; 7+ messages in thread
From: Tristan Gingold @ 2011-11-09 7:51 UTC (permalink / raw)
To: kidoshisama; +Cc: Marty McGowan, gdb, Joel Brobecker
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building on Darwin
2011-11-09 7:51 ` Tristan Gingold
@ 2011-12-23 5:46 ` alanandersen1
2011-12-23 10:32 ` Tristan Gingold
0 siblings, 1 reply; 7+ messages in thread
From: alanandersen1 @ 2011-12-23 5:46 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building on Darwin
2011-12-23 5:46 ` alanandersen1
@ 2011-12-23 10:32 ` Tristan Gingold
0 siblings, 0 replies; 7+ messages in thread
From: Tristan Gingold @ 2011-12-23 10:32 UTC (permalink / raw)
To: alanandersen1; +Cc: gdb
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.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-12-23 10:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-21 2:36 Building on Darwin Marty McGowan
2011-06-21 4:20 ` Joel Brobecker
2011-06-21 7:37 ` Tristan Gingold
2011-11-08 15:15 ` kidoshisama
2011-11-09 7:51 ` Tristan Gingold
2011-12-23 5:46 ` alanandersen1
2011-12-23 10:32 ` Tristan Gingold
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).