This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB on Mac OS
- From: Jack Howarth <howarth dot mailing dot lists at gmail dot com>
- To: "Paul_Koning at dell dot com" <Paul_Koning at dell dot com>
- Cc: brobecker at adacore dot com, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 12 Aug 2015 09:52:06 -0400
- Subject: Re: GDB on Mac OS
- Authentication-results: sourceware.org; auth=none
- References: <1739A299-ACE9-4D7F-A1DF-E64C89ECC8D1 at dell dot com> <20150812031208 dot GJ22225 at adacore dot com> <95D02D49-26D2-454E-8E11-70EBF7CB5EC5 at dell dot com>
On Wed, Aug 12, 2015 at 9:37 AM, <Paul_Koning@dell.com> wrote:
>
>> On Aug 11, 2015, at 11:12 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>
>>> I just test builds of the current gdb (GIT master) on Mac OS 10.10.4.
>>> I built it with the stock LLVM, then with GDB 5.2. Both require the
>>> configure switch --disable-build-warnings in order for things to build
>>> (the default blows up with compiler error messages).
>>
>> The fact that it has build warnings is not too surprising. Outside
>> of GNU/Linux, I'm not sure it's building warning-free on any
>> other host. Building with --disable-werror is how we do it.
>
> Ok, but it would make sense for the default configure to select the correct compile options that the build will run to completion.
>
>>
>>> I then ran âmake checkâ in the gdb subdirectory. The results were
>>> slightly different for the two builds, but in both I see about 5000
>>> pass and a bit over 4000 fail. Thatâs an awfully high fail
>>> percentage. Is that expected? Is GDB still intended to work on Mac
>>> OS? Should I report details on the failures, and if so, what should I
>>> report and what logs are needed?
>>
>> It's working pretty well for us. Probably not perfect, but fairly
>> well. A couple of things that come to mind:
>>
>> - I think we changed the default in AdaCore's compiler to build
>> with -fno-common, although I'm not certain. You might want to
>> try that and see if that brings you better results;
>>
>> - for actual debugging of a live inferior, the debugger needs
>> to be codesigned - try with a simple example first to see
>> if you can run a program and break somewhere.
>
> So is that the reason why so many tests fail? I know of the codesigning requirement from actually using the debugger (or rather, answering the prompt for my password, which is the alternative). Where would I look for information on how to do this? It would seem logical for âmake checkâ either to do it, or to report that it needs to be done.
>
The instructions we provide in the fink gdb packaging are....
To execute fsf-gdb without using sudo, the binary needs to be codesigned
on each machine that it is installed on. This requires the creation
of a certificate and signing of the fsf-gdb binary with the following
steps.
1) Open the application 'Keychain Access' from the Utilities folder.
2) In the Keychain Access application, select the 'Create a
Certificate...' submenu item from the 'Keychain Access' menu and
the 'Certificate Assistant' submenu.
3) In the 'Certificate Assistant' panel, enter 'gdb-cert' for the name
of the certificate and leave the Identity Type as 'Self Signed Root'.
Set the Certificate Type to 'Code Signing' and enable the 'Let me
override defaults' checkbox. Click the 'Continue' button. You may
wish to lengthen the default 365 day lifespan of the certificate
to 3650 days.
4) Continue clicking the 'Continue' buttons that appear until you see
the panel to 'Specify a Location For The Certificate'. Set the
Keychain to 'System' at this point. If you can't store the
certificate in the 'System' keychain, create it in the 'login'
keychain, then export it. You can then import it into the 'System'
keychain.
5) Select the 'System' entry in the Keychains listing of the Keychain
Access window. Select your newly created 'gdb-cert' certificate and
select the 'Get Info' contextual menu item, expand the 'Trust'
item and set 'Code Signing' to '"Always Trust'.
6) Quit the 'Keychain Access' application.
7) On darwin12 or later, you must edit the line in the file
/System/Library/LaunchDaemons/com.apple.taskgated.plist from
<string>-s</string>
to
<string>-sp</string>
adding the '-p' option. Due to kernel caching, a restart is needed
for the changes to take effect.
8) After the restart, the actual codesigning should be done with the
command 'sudo codesign -s gdb-cert %p/lib/fsf-gdb/fsf-gdb'. Note it
can take over five minutes for the codesigning to complete.
Of course you'll have to adjust the binary name and location for gdb
to where ever you installed it.
Jack
>>
>> MacOS 10.10 seems very old, at this point. We test on 13.4 and 14.3.
>
> Sorry, I confused things by talking about the OS version as opposed to the Darwin version. Itâs Mac OS X 10.10.4 (Yosemite), Darwin 14.4.0, x86_64.
>
> paul