GDB on Mac OS

GDB on Mac OS

[Paul_Koning]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 672 bytes --]

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

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?

	paul
\x16º&ÖëzÛ«ŸŽ9÷Ib²Ö«r\x18\x1d

Re: GDB on Mac OS

[Paul_Koning]

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

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

Re: GDB on Mac OS

[Jonas Maebe]

Paul_Koning wrote on Wed, 12 Aug 2015:

> On Aug 11, 2015, at 11:12 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>
>>  - 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).

It's not the alternative, both are required. You won't even get to the  
password prompt without a codesigned binary.

> Where would I look for information on how to do this?

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

In particular also note the addendum regarding taskgated: you also  
have to add the -p option to that LaunchDaemon plist and reboot before  
gdb will work for non-root users on OS X 10.9 and 10.10.


Jonas

Re: GDB on Mac OS

[Joel Brobecker]

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

This is really a separate discussion, but my take on it is that
the goal is to have warning-free builds on all platforms. Turning
this feature off for some targets would hide those warnings away,
and reduce our chances of anyone working on them. Building
a snapshot of the day is considered to be building GDB in developer
mode, so the warnings are fatal by default. If you were to build
from a release or from a release branch, on the other hand, the
configure settings have been changed to make the warnings non-fatal.

Note that having a warning-free build is not entirely within GDB's
control. For instance, you'll need a certain version of bison for
it to generate files that compile warning-free. I don't believe
it is worth spending time trying to come up with a list of tests
that will tell us whether warnings should be fatal or not.

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

I'm not a specialist, but I don't think codesigning can happen
automagically. Codesigning requires for instance the name of
a certificate, which is yours to choose. Creating that certificate
involves the use of graphical tools. That's why we left the codesigning
to the user - especially since the binaries are transportable but
the codesigning needs to be redone on every machine to match the
certificates provided by each machine.

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

-- 
Joel

Re: GDB on Mac OS

[Paul_Koning]

> On Aug 12, 2015, at 9:59 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> 
>>> 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.  
> 
> This is really a separate discussion, but my take on it is that
> the goal is to have warning-free builds on all platforms. Turning
> this feature off for some targets would hide those warnings away,
> and reduce our chances of anyone working on them. Building
> a snapshot of the day is considered to be building GDB in developer
> mode, so the warnings are fatal by default. If you were to build
> from a release or from a release branch, on the other hand, the
> configure settings have been changed to make the warnings non-fatal.
> 
> Note that having a warning-free build is not entirely within GDB's
> control. For instance, you'll need a certain version of bison for
> it to generate files that compile warning-free. I don't believe
> it is worth spending time trying to come up with a list of tests
> that will tell us whether warnings should be fatal or not.

Ok, thanks.  So that tells me that warnings should be considered issues to be fixed, rather than noise to be shut off or worked around.

Does that apply to LLVM warnings, too?  There are a whole lot of those.  Some are caused by sending GCC options to the compiler that LLVM doesn’t understand, in spite of the fact that it proclaims itself as GCC.  It seems that configure will need to be able to tell the difference and avoid triggering those LLVM incompatibilities.

> 
>> 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.
> 
> I'm not a specialist, but I don't think codesigning can happen
> automagically. Codesigning requires for instance the name of
> a certificate, which is yours to choose. Creating that certificate
> involves the use of graphical tools. That's why we left the codesigning
> to the user - especially since the binaries are transportable but
> the codesigning needs to be redone on every machine to match the
> certificates provided by each machine.
> 
> https://sourceware.org/gdb/wiki/BuildingOnDarwin

Yes, I see that now, and your reasoning looks correct.  The biggest trouble is that this information is buried in various places and has to be excavated.  It would help if there were an entry in the README file, or a BUILDING file, that either gives the information or points to it.

	paul

Re: GDB on Mac OS

[Joel Brobecker]

> Does that apply to LLVM warnings, too?  There are a whole lot of
> those.  Some are caused by sending GCC options to the compiler that
> LLVM doesn’t understand, in spite of the fact that it proclaims itself
> as GCC.  It seems that configure will need to be able to tell the
> difference and avoid triggering those LLVM incompatibilities.

I'm not sure about LLVM. I *think* that we're only aiming for
warning-free with GCC.

-- 
Joel

Re: GDB on Mac OS

[Stan Shebs]

On Wed, Aug 12, 2015 at 10:14 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Does that apply to LLVM warnings, too?  There are a whole lot of
>> those.  Some are caused by sending GCC options to the compiler that
>> LLVM doesn’t understand, in spite of the fact that it proclaims itself
>> as GCC.  It seems that configure will need to be able to tell the
>> difference and avoid triggering those LLVM incompatibilities.
>
> I'm not sure about LLVM. I *think* that we're only aiming for
> warning-free with GCC.

In practice, LLVM (more specifically Clang) has been including more
and more GCC flags, just because everybody wants warning-free and
nobody wants configure-hell. :-)

Clang warnings have been catching cases that GCC misses (quite a few
in the Google codebase, in fact), so it seems worthwhile to collect
and check those, at least periodically.

Stan