Re: Shipping core libraries with debug symbols
What about keeping exactly what -g1 keeps for gcc (i.e. functions, external variables, and line number tables)? On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann wrote: > > > Okay, I ran a little experiment - here's the size of the debug sections > that Fission would keep (for base library): > > .debug_abbrev: 8932 - 0.06% > .debug_line: 374134 - 2.6% > .debug_frame: 671200 - 4.5% > > Not that much. On the other hand, .debug_info is a significant contributor: > > .debug_info(full): 4527391 - 30% > > Here's what this contains: All procs get a corresponding DWARF entry, and > we declare all Cmm blocks as "lexical blocks". The latter isn't actually > required right now - to my knowledge, GDB simply ignores it, while LLDB > shows it as "inlined" routines. In either case, it just shows yet more > GHC-generated names, so it's really only useful for profiling tools that > know Cmm block names. > > So here's what we get if we strip out block information: > > .debug_info(!block): 1688410 - 11% > > This eliminates a good chunk of information, and might therefore be a good > idea for "-g1" at minimum. If we want this as default for 7.10, this would > make the total overhead about 18%. Acceptable? I can supply a patch if > needed. > > Just for comparison - for Fission we'd strip proc records as well, which > would cause even more extreme savings: > > .debug_info(!proc):36081 - 0.2% > > At this point the overhead would be just about 7% - but without doing > Fission properly this would most certainly affect debuggers. > > Greetings, > Peter > > On 03/01/2015 21:22, Johan Tibell wrote: > > How much debug info (as a percentage) do we currently generate? Could we > just keep it in there in the release? > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
Okay, I ran a little experiment - here's the size of the debug sections that Fission would keep (for base library): .debug_abbrev: 8932 - 0.06% .debug_line: 374134 - 2.6% .debug_frame: 671200 - 4.5% Not that much. On the other hand, .debug_info is a significant contributor: .debug_info(full): 4527391 - 30% Here's what this contains: All procs get a corresponding DWARF entry, and we declare all Cmm blocks as "lexical blocks". The latter isn't actually required right now - to my knowledge, GDB simply ignores it, while LLDB shows it as "inlined" routines. In either case, it just shows yet more GHC-generated names, so it's really only useful for profiling tools that know Cmm block names. So here's what we get if we strip out block information: .debug_info(!block): 1688410 - 11% This eliminates a good chunk of information, and might therefore be a good idea for "-g1" at minimum. If we want this as default for 7.10, this would make the total overhead about 18%. Acceptable? I can supply a patch if needed. Just for comparison - for Fission we'd strip proc records as well, which would cause even more extreme savings: .debug_info(!proc):36081 - 0.2% At this point the overhead would be just about 7% - but without doing Fission properly this would most certainly affect debuggers. Greetings, Peter On 03/01/2015 21:22, Johan Tibell wrote: > How much debug info (as a percentage) do we currently generate? Could we just keep it in there in the release? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.4.2 on Ubuntu Trusty
For transformers, I needed: diff --git a/Control/Monad/Trans/Error.hs b/Control/Monad/Trans/Error.hs index 0158a8a..0dea478 100644 --- a/Control/Monad/Trans/Error.hs +++ b/Control/Monad/Trans/Error.hs @@ -57,6 +57,10 @@ instance MonadPlus IO where mzero = ioError (userError "mzero") m `mplus` n = m `catchIOError` \_ -> n +instance Alternative IO where +empty = mzero +(<|>) = mplus + #if !(MIN_VERSION_base(4,4,0)) -- exported by System.IO.Error from base-4.4 catchIOError :: IO a -> (IOError -> IO a) -> IO a For hpc, I needed: Build-Depends: -base >= 4.4.1 && < 4.8, +base >= 4.4.1 && < 4.9, containers >= 0.4.1 && < 0.6, directory >= 1.1 && < 1.3, -time >= 1.2 && < 1.5 +time >= 1.2 && < 1.6 For hoopl, I needed: - Build-Depends: base >= 4.3 && < 4.8 + Build-Depends: base >= 4.3 && < 4.9 For the latter two, I think this should be a perfectly acceptable point release. For transformers, we could also just ifdef the Alternative into the GHC sources. Edward Excerpts from Herbert Valerio Riedel's message of 2015-01-04 00:22:28 -0800: > Hello Edward, > > On 2015-01-04 at 08:54:58 +0100, Edward Z. Yang wrote: > > [...] > > > There are also some changes to hoopl, transformers and hpc (mostly > > because their bootstrap libraries.) > > ...what kind of changes specifically? > > Once thing that needs to be considered is that we'd require to upstream > changes to transformers (it's not under GHC HQ's direct control) for a > transformers point(?) release ... and we'd need that as we can't release > any source-tarball that contains libraries (which get installed into the > pkg-db) that don't match their upstream version on Hackage. > > Cheers, > hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker error on OSX (symbol not found "_iconv")
On Sun, Jan 4, 2015 at 11:06 AM, Hemanth Kapila wrote: > I am not able to figure out the exact dependency issue here - apparently, > libHSrts cannot be built with the system version of libiconv (configure > step fails), while at the same time "ghc-stage1" relies on some system tool > that needs older version of libiconv. > Is that a fair picture of the problem? I wondered why this does not occur > for ghc-7.8.4 distributed sources. > So presumably ghc HEAD requires a newer iconv now, presumably for better encoding handling. Many things do, which is why both MacPorts and Homebrew include the newer one (and then must hack around incompatibility) instead of sticking to Apple's. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker error on OSX (symbol not found "_iconv")
Hi, Thanks for the reply. I understand that discrepancy between macports and system libraries are causing this issue but I am not using the environment variable DYLD_LIBRARY_PATH. More over, I can build ghc-7.8.4 from sources, with the same configuration options. I repeated it there. I thought it is likely that I should see the same issue there as well. I am not able to figure out the exact dependency issue here - apparently, libHSrts cannot be built with the system version of libiconv (configure step fails), while at the same time "ghc-stage1" relies on some system tool that needs older version of libiconv. Is that a fair picture of the problem? I wondered why this does not occur for ghc-7.8.4 distributed sources. I thought something got inadvertently modified in the compiler/main folder since the release of 7.8.4 and resulted in this issue. That's why I posted it over here. However, by the looks of it, it is just me.. Thanks again, Hemanth On Sun, Jan 4, 2015 at 7:45 PM, Brandon Allbery wrote: > On Sun, Jan 4, 2015 at 1:23 AM, Hemanth Kapila > wrote: > >> > ld: couldn't dlopen() /usr/lib/libdtrace.dylib: >> dlopen(/usr/lib/libdtrace.dylib, 1): Symbol not found: _iconv >> > Referenced from: /usr/lib/libmecabra.dylib >> > Expected in: /opt/local/lib/libiconv.2.dylib >> > in /usr/lib/libmecabra.dylib for architecture x86_64 >> > collect2: error: ld returned 1 exit status >> > > You are mixing Apple and MacPorts libraries. (The same will happen with > Homebrew but it'll be using /usr/local/lib/libiconv.2.dylib.) Possibly you > also have DYLIB_LIBRARY_PATH set, which will compound the problem; *please* > do not do this. You are not on Linux where setting LD_LIBRARY_PATH is > common and relatively safe, DYLIB_LIBRARY_PATH will break things. > > The iconv libraries contain static data which is not compatible between > versions, leading to core dumps unless something is done to force a link > time error. Both MacPorts and Homebrew rename symbols in iconv to force > this error. > > Since you are building ghc, either you have forced it to use MacPorts > libraries when it otherwise wouldn't (see above re DYLD_LIBRARY_PATH) or > you at some point copied MacPorts libraries into system library paths (OS X > bakes full paths into object files and dylibs. This also means such > libraries cannot be used on a system without MacPorts installed without at > minimum using install_name_tool to change the baked-in paths). > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- I drink I am thunk. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker error on OSX (symbol not found "_iconv")
On Sun, Jan 4, 2015 at 1:23 AM, Hemanth Kapila wrote: > > ld: couldn't dlopen() /usr/lib/libdtrace.dylib: > dlopen(/usr/lib/libdtrace.dylib, 1): Symbol not found: _iconv > > Referenced from: /usr/lib/libmecabra.dylib > > Expected in: /opt/local/lib/libiconv.2.dylib > > in /usr/lib/libmecabra.dylib for architecture x86_64 > > collect2: error: ld returned 1 exit status > You are mixing Apple and MacPorts libraries. (The same will happen with Homebrew but it'll be using /usr/local/lib/libiconv.2.dylib.) Possibly you also have DYLIB_LIBRARY_PATH set, which will compound the problem; *please* do not do this. You are not on Linux where setting LD_LIBRARY_PATH is common and relatively safe, DYLIB_LIBRARY_PATH will break things. The iconv libraries contain static data which is not compatible between versions, leading to core dumps unless something is done to force a link time error. Both MacPorts and Homebrew rename symbols in iconv to force this error. Since you are building ghc, either you have forced it to use MacPorts libraries when it otherwise wouldn't (see above re DYLD_LIBRARY_PATH) or you at some point copied MacPorts libraries into system library paths (OS X bakes full paths into object files and dylibs. This also means such libraries cannot be used on a system without MacPorts installed without at minimum using install_name_tool to change the baked-in paths). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.4.2 on Ubuntu Trusty
Hello Edward, On 2015-01-04 at 08:54:58 +0100, Edward Z. Yang wrote: [...] > There are also some changes to hoopl, transformers and hpc (mostly > because their bootstrap libraries.) ...what kind of changes specifically? Once thing that needs to be considered is that we'd require to upstream changes to transformers (it's not under GHC HQ's direct control) for a transformers point(?) release ... and we'd need that as we can't release any source-tarball that contains libraries (which get installed into the pkg-db) that don't match their upstream version on Hackage. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
