[devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Evgeny Sinelnikov]

Доброй ночи,

хочу обратиться за помощью с проблемой с debugedit при сборке
ghc-9.2.8 на aarch64.
_________________________

При сборке новой версии ghc на aarch64 отваливается
find-debuginfo-files. Для x86_64, i586 и ppc64le сборка прошла
успешно.

Из относительно понятного вижу только три строки:
debugedit: Cannot handle 8-byte build ID
getOutputFrom(): Broken pipe
Command exited with non-zero status 1

В скрипте не отрабатывает следующий кусок:
...
debugf=./usr/lib/debug$f.debug
...
id=$(debugedit -n -i "$debugf")
...

То есть на aarch64 debugedit отваливается в функции handle_build_id():
/* Compute a fresh build ID bit-string from the editted file contents.  */
...
Судя по всему для получившихся бинарей не поддерживается вычисление хеш-суммы:
  /* For now we only handle 16 byte (128 bits) with md5 or 20 bytes
     (160 bits) with sha1.  */
_________________________

Вопрос. Что с этим можно сделать?

_________________________

#330113 FAILING #1 [locked] sisyphus ghc.git=9.2.8-alt1

https://git.altlinux.org/tasks/330113/build/100/aarch64/log
...
[01:34:52] Requires(rpmlib): rpmlib(SetVersions)
[01:34:52] Requires(pre): haskell-filetrigger >= 0.0.5-alt3
[01:34:52] Requires(postun): haskell-filetrigger >= 0.0.5-alt3
[01:34:52] Finding debuginfo files (using /usr/lib/rpm/find-debuginfo-files)
[01:34:52] Executing: /bin/sh -e /usr/src/tmp/rpm-tmp.QXqo8S
[01:34:52] debugedit: Cannot handle 8-byte build ID
[01:34:52] getOutputFrom(): Broken pipe
[01:34:52] Command exited with non-zero status 1
[01:34:52] 31416.24user 1994.08system 1:34:46elapsed 587%CPU
(0avgtext+0avgdata 5536976maxresident)k
[01:34:52] 0inputs+0outputs (0major+361226973minor)pagefaults 0swaps
[01:34:52] hsh-rebuild: rebuild of `ghc9.2.8-9.2.8-alt1.src.rpm' failed.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Vitaly Chikunov]

Hi,

On Sat, Sep 23, 2023 at 01:51:59AM +0300, Evgeny Sinelnikov wrote:
> хочу обратиться за помощью с проблемой с debugedit при сборке
> ghc-9.2.8 на aarch64.
> _________________________
> 
> При сборке новой версии ghc на aarch64 отваливается
> find-debuginfo-files. Для x86_64, i586 и ppc64le сборка прошла
> успешно.
> 
> Из относительно понятного вижу только три строки:
> debugedit: Cannot handle 8-byte build ID
> getOutputFrom(): Broken pipe
> Command exited with non-zero status 1
> 
> В скрипте не отрабатывает следующий кусок:
> ...
> debugf=./usr/lib/debug$f.debug
> ...
> id=$(debugedit -n -i "$debugf")
> ...
> 
> То есть на aarch64 debugedit отваливается в функции handle_build_id():
> /* Compute a fresh build ID bit-string from the editted file contents.  */
> ...
> Судя по всему для получившихся бинарей не поддерживается вычисление хеш-суммы:
>   /* For now we only handle 16 byte (128 bits) with md5 or 20 bytes
>      (160 bits) with sha1.  */
> _________________________
> 
> Вопрос. Что с этим можно сделать?

eu-readelf -n на бинарник. Там должно быт скажем так:

  Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x378:
    Owner          Data size  Type
    GNU                   20  GNU_BUILD_ID
      Build ID: a41b2e353297560c24bed084d721b22dd6ca7b15

Судя по ошибке там 8-байтовое значение. Нужно - выяснить почему
компилятор (только) для этой архитектуры поставил такое короткое
значение и исправить это.

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Dmitry V. Levin]

On Sat, Sep 23, 2023 at 03:44:57PM +0700, Ilya Kurdyukov wrote:
> Видимо для aarch64 был использован xxhash.
> 
> Возможно помогут ссылки из этого обсуждения:
> 
> https://github.com/rpm-software-management/rpm/issues/950
> 
> Например это, из упомянутого там коммита:
> 
>  > --ldflags=-Wl,--build-id=sha1

Этой истории уже много лет, поэтому удивительно, что где-то до сих пор
по умолчанию создаётся 64-битный build id.  С точки зрения репозитория
важно не столько, чтобы конкретный пакет был исправлен, сколько чтобы
этого не происходило по умолчанию.


-- 
ldv

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Ilya Kurdyukov]

On 9/23/23 16:36, Dmitry V. Levin wrote:
>>   > --ldflags=-Wl,--build-id=sha1
> Этой истории уже много лет, поэтому удивительно, что где-то до сих пор
> по умолчанию создаётся 64-битный build id.  С точки зрения репозитория
> важно не столько, чтобы конкретный пакет был исправлен, сколько чтобы
> этого не происходило по умолчанию.
>
ghc (смотрел спеку 8.6.4) для armh/aarch64 собирается через LLVM:

* Thu Aug 17 2023 Anton Zhukharev <ancieg@altlinux.org> 8.6.4-alt9
- Fixed FTBFS.
- Built with llvm12.0 on armh and aarch64.
- Stored LLVM version in %%ghc_llvm_version macro.

Это опции LLD, линковщика из LLVM:

--build-id=value
     Generate a build ID note. value may be one of fast, md5, sha1, 
tree, uuid, 0xhex-string, and none. tree is an alias for sha1. Build-IDs 
of type fast, md5, sha1, and tree are calculated from the object 
contents. fast is not intended to be cryptographically secure.
--build-id
     Synonym for --build-id=fast.

Если девятый ghc собирается так же - значит проблема в конфигурации 
LLVM, наверное там указано --build-id, что превращается в --build-id=fast.

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Evgeny Sinelnikov]

Приветствую.

сб, 23 сент. 2023 г. в 12:44, Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>
> On 9/23/23 16:36, Dmitry V. Levin wrote:
> >>   > --ldflags=-Wl,--build-id=sha1
> > Этой истории уже много лет, поэтому удивительно, что где-то до сих пор
> > по умолчанию создаётся 64-битный build id.  С точки зрения репозитория
> > важно не столько, чтобы конкретный пакет был исправлен, сколько чтобы
> > этого не происходило по умолчанию.
> >
> ghc (смотрел спеку 8.6.4) для armh/aarch64 собирается через LLVM:
[...]
> Это опции LLD, линковщика из LLVM:
>
[...]
> Если девятый ghc собирается так же - значит проблема в конфигурации
> LLVM, наверное там указано --build-id, что превращается в --build-id=fast.

ghc/mk/config.mk.in:
[...]
# Set to YES if ld has the --build-id flag.  Sometimes we need to
# disable it with --build-id=none.
LdHasBuildId<-->        = @LdHasBuildId@
[...]

Далее в коде не так много упоминаний об этом:

ghc/compiler/GHC/Driver/Pipeline/Execute.hs
[...]
Note [Merging object files for GHCi]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GHCi can usually loads standard linkable object files using GHC's linker
implementation. However, most users build their projects with -split-sections,
meaning that such object files can have an extremely high number of sections.
As the linker must map each of these sections individually, loading such object
files is very inefficient.

To avoid this inefficiency, we use the linker's `-r` flag and a linker script
to produce a merged relocatable object file. This file will contain a singe
text section section and can consequently be mapped far more efficiently. As
gcc tends to do unpredictable things to our linker command line, we opt to
invoke ld directly in this case, in contrast to our usual strategy of linking
via gcc.
-}

-- | See Note [Object merging].
joinObjectFiles :: HscEnv -> [FilePath] -> FilePath -> IO ()
joinObjectFiles hsc_env o_files output_fn
  | can_merge_objs = do
  let toolSettings' = toolSettings dflags
      ldIsGnuLd = toolSettings_ldIsGnuLd toolSettings'
      ld_r args = GHC.SysTools.runMergeObjects (hsc_logger hsc_env)
(hsc_tmpfs hsc_env) (hsc_dflags hsc_env) (
                        map GHC.SysTools.Option ld_build_id
                     ++ [ GHC.SysTools.Option "-o",
                          GHC.SysTools.FileOption "" output_fn ]
                     ++ args)

      -- suppress the generation of the .note.gnu.build-id section,
      -- which we don't need and sometimes causes ld to emit a
      -- warning:
      ld_build_id | toolSettings_ldSupportsBuildId toolSettings' =
["--build-id=none"]
                  | otherwise                                    = []
[...]

Ну, то есть, немного наоборот, вероятно, получается. --build-id явно
не указывается, а если и указывается, то в виде --build-id=none.


При этом вот такой вывод от бинаря

$ debugedit -i ./rts/dist/build/libHSrts_thr-ghc9.2.8.so
debugedit: Cannot handle 8-byte build ID

[builder@localhost ghc9.2.8-9.2.8]$ eu-readelf -n
./rts/dist/build/libHSrts_thr-ghc9.2.8.so | head

Note section [ 1] '.note.gnu.build-id' of 24 bytes at offset 0x270:
  Owner          Data size  Type
  GNU                    8  GNU_BUILD_ID
    Build ID: ba79f50a6074df4d


--
Sin (Sinelnikov Evgeny)

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]

On Sat, Sep 23, 2023 at 04:44:38PM +0700, Ilya Kurdyukov wrote:
> On 9/23/23 16:36, Dmitry V. Levin wrote:
> > >   > --ldflags=-Wl,--build-id=sha1
> > Этой истории уже много лет, поэтому удивительно, что где-то до сих пор
> > по умолчанию создаётся 64-битный build id.  С точки зрения репозитория
> > важно не столько, чтобы конкретный пакет был исправлен, сколько чтобы
> > этого не происходило по умолчанию.
> > 
> ghc (смотрел спеку 8.6.4) для armh/aarch64 собирается через LLVM:
> 
> * Thu Aug 17 2023 Anton Zhukharev <ancieg@altlinux.org> 8.6.4-alt9
> - Fixed FTBFS.
> - Built with llvm12.0 on armh and aarch64.
> - Stored LLVM version in %%ghc_llvm_version macro.
> 
> Это опции LLD, линковщика из LLVM:
> 
> --build-id=value
>     Generate a build ID note. value may be one of fast, md5, sha1, tree,
> uuid, 0xhex-string, and none. tree is an alias for sha1. Build-IDs of type
> fast, md5, sha1, and tree are calculated from the object contents. fast is
> not intended to be cryptographically secure.
> --build-id
>     Synonym for --build-id=fast.
> 
> Если девятый ghc собирается так же - значит проблема в конфигурации LLVM,
> наверное там указано --build-id, что превращается в --build-id=fast.

Мы (т. е. я и не только) тут off-list голову ломали, почему ошибка, о
которой речь в этом треде, происходит только на aarch64 и почему мы
подобных жалоб не видим по всему репозиторию среди пакетов, линкуемых
этим lld. А дело в том, что на данной архитектуре в данном пакете lld
вызывается командой gcc, что редкость (не удивлюсь, если в сизифе так
делает только сборочная система ghc). gcc, вестимо, передаёт линкеру
просто --build-id.

Так что большое спасибо Илье за оперативное замечание в яблочко. И
тогда, действительно, проще всего навязать в пакете ghcX
`--ldflags=-Wl,--build-id=sha1'.


Хуже того, clang (и актуальный тоже) вообще не передаёт --build-id=*, т.
е. у нас все бинарники из-под clang+lld попадают в репозиторий вообще
без GNU_BUILD_ID elf note.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Ilya Kurdyukov]

On 9/28/23 06:05, Arseny Maslennikov wrote:
>
> Хуже того, clang (и актуальный тоже) вообще не передаёт --build-id=*, т.
> е. у нас все бинарники из-под clang+lld попадают в репозиторий вообще
> без GNU_BUILD_ID elf note.
>
Искал поиском по исходникам ghc-9.2.8, нашел что там проверяется, 
поддерживается ли опция --build-id=none, и такая используется если 
поддерживается. В каких случаях это используется - не знаю, может всегда.


При сборке clang есть такая опция для cmake:

set(ENABLE_LINKER_BUILD_ID OFF CACHE BOOL "pass --build-id to ld")

Что включает код:

clang/lib/Driver/ToolChains/Linux.cpp

#ifdef ENABLE_LINKER_BUILD_ID
   ExtraOpts.push_back("--build-id");
#endif

Который можно пропатчить для Альта, убрав #ifdef и указав правильную 
опцию для --build-id, не доверяя значению по умолчанию.

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Evgeny Sinelnikov]

Доброй ночи,

попробовал два варианта решения:
1) Выставил опцию --disable-ld-override, которая напрямую запускает ld
- отвалился armh:
https://git.altlinux.org/tasks/330113

2) Пропатчил ghc - явно указал --build-id=sha1 для линкера - отвалился
aarch64, но armh успешно собрался:
https://git.altlinux.org/tasks/332192

Итого, похоже, для aarch64 во втором случае не хватило ресурсов на
сборочной ноде.
Может ли кто-нибудь проверить?


чт, 28 сент. 2023 г. в 05:19, Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>
>
> On 9/28/23 06:05, Arseny Maslennikov wrote:
> >
> > Хуже того, clang (и актуальный тоже) вообще не передаёт --build-id=*, т.
> > е. у нас все бинарники из-под clang+lld попадают в репозиторий вообще
> > без GNU_BUILD_ID elf note.
> >
> Искал поиском по исходникам ghc-9.2.8, нашел что там проверяется,
> поддерживается ли опция --build-id=none, и такая используется если
> поддерживается. В каких случаях это используется - не знаю, может всегда.
>
>
> При сборке clang есть такая опция для cmake:
>
> set(ENABLE_LINKER_BUILD_ID OFF CACHE BOOL "pass --build-id to ld")
>
> Что включает код:
>
> clang/lib/Driver/ToolChains/Linux.cpp
>
> #ifdef ENABLE_LINKER_BUILD_ID
>    ExtraOpts.push_back("--build-id");
> #endif
>
> Который можно пропатчить для Альта, убрав #ifdef и указав правильную
> опцию для --build-id, не доверяя значению по умолчанию.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Проблема с debugedit при сборке ghc-9.2.8 на aarch64

[Ivan A. Melnikov]

On Fri, Oct 20, 2023 at 02:40:58AM +0400, Evgeny Sinelnikov wrote:
> 2) Пропатчил ghc - явно указал --build-id=sha1 для линкера - отвалился
> aarch64, но armh успешно собрался:
> https://git.altlinux.org/tasks/332192
> 
> Итого, похоже, для aarch64 во втором случае не хватило ресурсов на
> сборочной ноде.

Не похоже:

[01:38:51] Finding debuginfo files (using /usr/lib/rpm/find-debuginfo-files)
[01:38:51] Executing: /bin/sh -e /usr/src/tmp/rpm-tmp.F9Gs9T
[01:38:51] debugedit: Cannot handle 8-byte build ID
[01:38:51] getOutputFrom(): Broken pipe
[01:38:51] Command exited with non-zero status 1

-- 
  wbr,
    iv m.