- ghc-devs - Haskell.org

Re: How do I find out which info table a continuation belongs to?
by Ömer Sinan Ağacan 02 May '19

02 May '19

Bumping thread, this is still a problem for me. I wonder if this ever worked. I should try this with older GHCs. Ömer Sergei Azovskov <lastg(a)fb.com>, 26 Şub 2019 Sal, 19:21 tarihinde şunu yazdı: > > Hey! > > Unfortunately, I'm not a big expert in gdb and debugging ghc runtime. I stripped some auto generated symbols from the symtab but they can still be found in dwarf section. I don't know how to force gdb to show them but you can manually check via dwarfdump. > ________________________________ > From: Ömer Sinan Ağacan <omeragacan(a)gmail.com> > Sent: Sunday, February 10, 2019 6:45 PM > To: Simon Marlow > Cc: ghc-devs; Sergei Azovskov > Subject: Re: How do I find out which info table a continuation belongs to? > > I'm already using -g3. Here's my build.mk: > > BuildFlavour = quick > > ifneq "$(BuildFlavour)" "" > include mk/flavours/$(BuildFlavour).mk > endif > > GhcRtsHcOpts += -O0 -g3 > SRC_HC_OPTS += -g3 > GhcStage1HcOpts += -g3 > GhcStage2HcOpts += -g3 > GhcLibHcOpts += -g3 > > STRIP_CMD = : > > Ömer > > Simon Marlow <marlowsd(a)gmail.com>, 10 Şub 2019 Paz, 19:00 tarihinde şunu yazdı: > > > > I believe this is due to https://urldefense.proofpoint.com/v2/url?u=https-3A__phabricator.haskell.or… > > > > (cc Sergei Azovskov) > > > > I'm a bit surprised that gdb isn't showing anything though, it should know that the address corresponds to a temporary symbol like `.L1234`. Perhaps you need to compile with -g to make this work, I'm not sure. > > > > On Sun, 10 Feb 2019 at 07:50, Ömer Sinan Ağacan <omeragacan(a)gmail.com> wrote: > >> > >> I'm currently working on a bug and one of the things I often want to know is > >> what's on the stack. The problem is I can't see labels of continuations so the > >> information is really useless. Example: > >> > >> >>> call printStack(((StgTSO*)0x42000e0198)->stackobj) > >> 0x42000c8788: RET_SMALL (0x512d70) > >> 0x42000c8790: RET_SMALL (0x40edf0) > >> stk[5] (0x42000c8798) = 0x7b3938 > >> 0x42000c87a0: CATCH_FRAME(0x735a98,0x7d3ff2) > >> 0x42000c87b8: STOP_FRAME(0x7311b8) > >> > >> (I modified the printer to print stack locations when printing stacks) > >> > >> Here I need to know which info table the RET_SMALLs return to. Normally I do > >> this for other kinds of closures: > >> > >> >>> print ((StgClosure*)...)->header.info > >> $15 = (const StgInfoTable *) 0x404dc0 <Main_nats_info> > >> > >> But for continuations that doesn't work: > >> > >> >>> print ((StgClosure*)0x42000c8788)->header.info > >> $11 = (const StgInfoTable *) 0x512d80 > >> >>> info symbol 0x512d80 > >> No symbol matches 0x512d80. > >> > >> Anyone know how to make this work? Can I maybe mark the continuations label in > >> the generated assembly somehow to make those labels available in gdb? > >> > >> Thanks > >> > >> Ömer > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs(a)haskell.org > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2D…

1 1

RE: ZuriHac 2019 - GHC Track
by Andrey Mokhov 01 May '19

01 May '19

Hi all, I am happy to help with Hadrian, perhaps giving an overview of the codebase and a quick demo covering typical use-cases. I'll generally be around to help with any build related issues, Hadrian hacking, etc. Note: I'm attending full days on Friday and Saturday, but on Sunday I may be available only in the morning. Cheers, Andrey ======================================= Dear GHC devs, This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. It was a great success last year, and we hope it will be a great success this year as well. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Continuous Integration / DevOps, by Manual Chakravarty - PrimOps / PrimTypes, by Michal Terepeta - Performance Regression Tests, by Niklas Hambüchen - Newcomers Tutorial, by Andreas Herrmann Other possible subjects could be around: - Improving documentation - Extending GHC's test-suite - General GHC development workflows - The inner workings of some aspect of GHC Aside from preparing a session, we are also looking for volunteers to be around as GHC mentors during hack sessions to help out newcomers. Please let us know if you'd be interested in leading a session, or being a mentor, or helping out with this track in any other way. You can contact either Niklas or myself, on this list or by private message. Best, Niklas and Andreas ZuriHac 2019 GHC track coordinators [1]: https://zfoh.ch/zurihac2019/

1 0

GHC HEAD documentation once again available
by Ben Gamari 01 May '19

01 May '19

TL;DR. A snapshot of GHC's documentation from the master branch can always be found at [2]. Hi everyone, Quite a while ago I made it a habit of periodically pushing documentation snapshots from GHC's master branch to downloads.haskell.org [1]. Unfortunately, despite some attempts at automating this process, this frequently grew out-of-date. I am happy to report that documentation snapshots are now generated as a product of GHC's CI process and made available here [2]. The old downloads.haskell.org URL redirects to [2] and consequently should now always be up-to-date. Let me know if you notice anything amiss. Cheers, - Ben [1] https://downloads.haskell.org/ghc/master/ [2] https://ghc.gitlab.haskell.org/ghc/doc/

4 6

GHC user manual
by Simon Peyton Jones 30 Apr '19

30 Apr '19

Where is the latest GHC user manual. I tried https://ghc.gitlab.haskell.org/ghc/doc/ but got a 502 failure. It would be good if it was easy to find the link from the developers home page https://gitlab.haskell.org/ghc/ghc/wikis/home Simon

2 4

GHC loose ends
by Simon Peyton Jones 30 Apr '19

30 Apr '19

Friends Like many people, I use my inbox as a to-do list. Over time, despite my best efforts, I accumulate a rising tide of GHC-related things (mostly tickets) where I feel I should do something, but it'd take too long to do today, so maybe tomorrow. Periodically I sweep all these into another folder, which makes me feel less oppressed by backlog. So this email is just to say: if you are waiting for some kind of response from me, please fell free to ping me. Simon

1 0

Type Annotations in the Presence of Injective Type Families, Bidirectional Pattern Synonyms, and Data Kinds
by Travis Whitaker 30 Apr '19

30 Apr '19

Hello GHC Devs, I've found a case in which annotating a bidirectional pattern synonym with a type signature causes the typechecker to reject an otherwise typeable program. Before filing a bug report I want to check that I'm thinking about this correctly. Consider this module: {-# LANGUAGE TypeFamilies , TypeFamilyDependencies , DataKinds , TypeOperators , GADTs , FlexibleContexts , PatternSynonyms #-} module Strange where data Expr a where Tuple :: NTup ts -> Expr (Flatten ts) data NTup (ts :: [*]) where Unit :: NTup '[] Pair :: Expr a -> NTup ts -> NTup (a ': ts) type family Flatten ts = r | r -> ts where Flatten '[] = () Flatten '[a, b] = (a, b) pattern P a b = Pair a (Pair b Unit) fstExpr :: Expr (a, b) -> (Expr a, Expr b) fstExpr (Tuple (P x y)) = (x, y) The idea is that an NTup '[a, b, c ...] should be isomorphic to an (a, b, c, ...), but removes a lot of repetitive code for dealing with Exprs of tuples. This module compiles with GHC 8.6.4 and GHC infers the expected type for P. P :: Expr a -> Expr a1 -> NTup '[a, a1] However, annotating P with this type causes typechecking fstExpr to fail with: Strange.hs:26:17: error: • Could not deduce: ts ~ '[a, b] from the context: (a, b) ~ Flatten ts bound by a pattern with constructor: Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), in an equation for ‘fstExpr’ at Strange.hs:26:10-22 ‘ts’ is a rigid type variable bound by a pattern with constructor: Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), in an equation for ‘fstExpr’ at Strange.hs:26:10-22 Expected type: NTup ts Actual type: NTup '[a, b] • In the pattern: P x y In the pattern: Tuple (P x y) In an equation for ‘fstExpr’: fstExpr (Tuple (P x y)) = (x, y) • Relevant bindings include fstExpr :: Expr (a, b) -> (Expr a, Expr b) (bound at Strange.hs:26:1) | 26 | fstExpr (Tuple (P x y)) = (x, y) | ^^^^^ It seems that providing a type signature causes GHC to forget the injectivity of Flatten (i.e (a, b) ~ Flatten ts implies ts ~ '[a, b]). Is this a bug, some limitation of pattern synonyms, or am I missing something? Thanks as always, Travis

2 2

Why not short out IND_STATICs in the GC?
by Ömer Sinan Ağacan 29 Apr '19

29 Apr '19

Hi Simon, I'm wondering why in the GC we don't short out IND_STATICs like we do in INDs and BLACKHOLEs. Is there a reason for that? In this code in evacuate(): case IND_STATIC: evacuate_static_object(IND_STATIC_LINK((StgClosure *)q), q); return; Why not do something like case IND_STATIC: q = ((StgIndStatic*)q)->indirectee; *p = q; goto loop; I actually tried it and it broke a lot of things, but I don't understand why. We basically turn this heap closure -> IND_STATIC -> heap closure into heap closure -> heap closure To me this should work, but for some reason it doesn't. Could you comment on why this doesn't work? Thanks, Ömer

2 1

Locations in the codegen where we assume pointers tagged with certain values?
by Ömer Sinan Ağacan 27 Apr '19

27 Apr '19

Hi all, I'm trying to find all places in the code generator where we assume that a pointer is tagged with a certain value. A generated code for this looks like this: mov 0x6(%rbx),%rax This moves payload[0] of the closure in %rbx to %rax, but it assumes that %rbx is tagged with 2 so it does 0x6(%rbx) instead of 0x8(%rbx). Anyone know where I should be looking at? Context: I'm implementing shorting out indirections in the concurrent collector. The code is quite similar to the current collector, except we do a cas() when updating the IND/BLACKHOLE pointer with the pointer to the indirectee. The problem is this causes all kinds of problems, in our debugging mostly caused by pointer misalignment. One concrete example of where this happens is we do mov 0x6(%rbx),%rax but the pointer in %rbx is actually tagged 3 instead of 2. The reason is I think we're breaking some invariants in the generated code where we assume certain tags from pointers (2 in the example above), but I couldn't find where in the code generator we do this. Thanks, Ömer

2 2

Gitlab down
by Ben Gamari 26 Apr '19

26 Apr '19

Due to an unfortunate mis-typing of the word "restart" gitlab.haskell.org is currently rebooting. I'll let you know when it's back up. Cheers, - Ben

1 0

Re: [ANNOUNCE] GHC 8.8.1-alpha1 is now available
by Ryan Scott 26 Apr '19

26 Apr '19

The 8.8 Migration Guide can be found here: https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8 Ryan S.

1 0