Opened 2 years ago

Closed 2 years ago

Last modified 7 months ago

#14221 closed bug (fixed)

yaml-0.8.23.3 fails to build with -g

Reported by: bgamari Owned by:
Priority: normal Milestone: 8.4.1
Component: Compiler (NCG) Version: 8.2.1
Keywords: DWARF Cc: niteria
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D3977
Wiki Page:

Description (last modified by bgamari)

yaml-0.8.23.3 fails to build with an assembler error,

$ cabal unpack yaml-0.8.23.3
$ ghc Data/Yaml/Internal.hs -O -g -keep-tmp-files -ddump-cmm -ddump-to-file -ddump-stg -ddump-cmm-verbose
[2 of 2] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, Data/Yaml/Internal.o )
/tmp/ghc26515_0/ghc_6.s: Assembler messages:

/tmp/ghc26515_0/ghc_6.s:64491:0: error:
     Error: can't resolve `.LcsyP_entry_end' {*UND* section} - `csyP_entry' {*UND* section}
      |
64491 |         .quad .LcsyP_entry_end-csyP_entry
      | ^
`gcc' failed in phase `Assembler'. (Exit code: 1)

Strangely enough, there are local symbols .LcsyP and .LcsyP_end are defined in the resulting assembler (as local labels within DataziYamlziInternal_zdwisNumeric_info), but not .LcsyP_entry_end nor csyP_entry.

Change History (8)

comment:1 Changed 2 years ago by bgamari

Description: modified (diff)

Here is a minimal reproducer,

module T14221 where

import Data.Text as T

isNumeric :: Text -> Bool
isNumeric t =
    T.all isNumeric' t && T.any isNumber t
  where
    isNumber c = '0' <= c && c <= '9'
    isNumeric' c = isNumber c
                || c == 'e'
                || c == 'E'
                || c == '.'
                || c == '-'
                || c == '+'

comment:2 Changed 2 years ago by bgamari

Differential Rev(s): Phab:D3977
Status: newpatch

comment:3 Changed 2 years ago by bgamari

Cc: niteria added

Bartosz, I believe you reported encountering this issue while using -g at some point.

comment:4 Changed 2 years ago by niteria

That looks exactly like my problem, thanks for the ping and the fix!

comment:5 Changed 2 years ago by Ben Gamari <ben@…>

In 8b007ab/ghc:

nativeGen: Consistently use blockLbl to generate CLabels from BlockIds

This fixes #14221, where the NCG and the DWARF code were apparently
giving two different names to the same block.

Test Plan: Validate with DWARF support enabled.

Reviewers: simonmar, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14221

Differential Revision: https://phabricator.haskell.org/D3977

comment:6 Changed 2 years ago by bgamari

Resolution: fixed
Status: patchclosed

comment:7 Changed 23 months ago by Ben Gamari <ben@…>

In 048a913/ghc:

cmm: Use LocalBlockLabel instead of AsmTempLabel to represent blocks

blockLbl was originally changed in 8b007abbeb3045900a11529d907a835080129176 to
use mkTempAsmLabel to fix an inconsistency resulting in #14221. However, this
breaks the C code generator, which doesn't support AsmTempLabels (#14454).

Instead let's try going the other direction: use a new CLabel variety,
LocalBlockLabel. Then we can teach the C code generator to deal with
these as well.

comment:8 Changed 7 months ago by bgamari

Keywords: DWARF added
Note: See TracTickets for help on using tickets.