Re: [PATCH] Add support for LoongArch

[Hengqi Chen via Elfutils-devel]

Hi, Mark:

Any comments? Thanks.

With this patch, pahole is now able to convert dwarf to BTF on
LoongArch machine.


cheers,
--
Hengqi


On Sat, Dec 3, 2022 at 9:47 PM Hengqi Chen  wrote:
>
> This implements initial support for the LoongArch architecture.
>
> Signed-off-by: Hengqi Chen 
> ---
>  backends/ChangeLog   |  7 
>  backends/Makefile.am |  7 +++-
>  backends/loongarch_init.c| 50 ++
>  backends/loongarch_reloc.def | 81 
>  backends/loongarch_symbol.c  | 74 
>  libebl/ChangeLog |  4 ++
>  libebl/eblopenbackend.c  |  2 +
>  src/ChangeLog|  4 ++
>  src/elflint.c|  2 +-
>  9 files changed, 228 insertions(+), 3 deletions(-)
>  create mode 100644 backends/loongarch_init.c
>  create mode 100644 backends/loongarch_reloc.def
>  create mode 100644 backends/loongarch_symbol.c
>
> diff --git a/backends/ChangeLog b/backends/ChangeLog
> index 5b0daffe..5813ddcc 100644
> --- a/backends/ChangeLog
> +++ b/backends/ChangeLog
> @@ -1,3 +1,10 @@
> +2022-12-02  Hengqi Chen  
> +
> +   * Makefile.am (modules): Add loongarch.
> +   * loongarch_init.c: New file.
> +   * loongarch_reloc.def: New file.
> +   * loongarch_symbol.c: New file.
> +
>  2022-08-09  Andreas Schwab  
>
> * riscv_init.c (riscv_init): HOOK segment_type_name,
> diff --git a/backends/Makefile.am b/backends/Makefile.am
> index 9566377f..0824123d 100644
> --- a/backends/Makefile.am
> +++ b/backends/Makefile.am
> @@ -37,7 +37,7 @@ AM_CPPFLAGS += -I$(top_srcdir)/libebl 
> -I$(top_srcdir)/libasm \
>  noinst_LIBRARIES = libebl_backends.a libebl_backends_pic.a
>
>  modules = i386 sh x86_64 ia64 alpha arm aarch64 sparc ppc ppc64 s390 \
> - m68k bpf riscv csky
> + m68k bpf riscv csky loongarch
>
>  i386_SRCS = i386_init.c i386_symbol.c i386_corenote.c i386_cfi.c \
> i386_retval.c i386_regs.c i386_auxv.c \
> @@ -96,11 +96,14 @@ riscv_SRCS = riscv_init.c riscv_symbol.c riscv_cfi.c 
> riscv_regs.c \
>  csky_SRCS = csky_attrs.c csky_init.c csky_symbol.c csky_cfi.c \
> csky_regs.c csky_initreg.c csky_corenote.c
>
> +loongarch_SRCS = loongarch_init.c loongarch_symbol.c
> +
>  libebl_backends_a_SOURCES = $(i386_SRCS) $(sh_SRCS) $(x86_64_SRCS) \
> $(ia64_SRCS) $(alpha_SRCS) $(arm_SRCS) \
> $(aarch64_SRCS) $(sparc_SRCS) $(ppc_SRCS) \
> $(ppc64_SRCS) $(s390_SRCS) \
> -   $(m68k_SRCS) $(bpf_SRCS) $(riscv_SRCS) 
> $(csky_SRCS)
> +   $(m68k_SRCS) $(bpf_SRCS) $(riscv_SRCS) 
> $(csky_SRCS) \
> +   $(loongarch_SRCS)
>
>  libebl_backends_pic_a_SOURCES =
>  am_libebl_backends_pic_a_OBJECTS = $(libebl_backends_a_SOURCES:.c=.os)
> diff --git a/backends/loongarch_init.c b/backends/loongarch_init.c
> new file mode 100644
> index ..a8ed9e81
> --- /dev/null
> +++ b/backends/loongarch_init.c
> @@ -0,0 +1,50 @@
> +/* Initialization of LoongArch specific backend library.
> +   Copyright (C) 2022 Hengqi Chen
> +   This file is part of elfutils.
> +
> +   This file is free software; you can redistribute it and/or modify
> +   it under the terms of either
> +
> + * the GNU Lesser General Public License as published by the Free
> +   Software Foundation; either version 3 of the License, or (at
> +   your option) any later version
> +
> +   or
> +
> + * the GNU General Public License as published by the Free
> +   Software Foundation; either version 2 of the License, or (at
> +   your option) any later version
> +
> +   or both in parallel, as here.
> +
> +   elfutils is distributed in the hope that it will be useful, but
> +   WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   General Public License for more details.
> +
> +   You should have received copies of the GNU General Public License and
> +   the GNU Lesser General Public License along with this program.  If
> +   not, see .  */
> +
> +#ifdef HAVE_CONFIG_H
> +# include 
> +#endif
> +
> +#define BACKENDloongarch_
> +#define RELOC_PREFIX   R_LARCH_
> +#include "libebl_CPU.h"
> +
> +/* This defines the common reloc hooks based on loongarch_reloc.def.  */
> +#include "common-reloc.c"
> +
> +
> +Ebl *
> +loongarch_init (Elf *elf __attribute__ ((unused)),
> +   GElf_Half machine __attribute__ ((unused)),
> +   Ebl *eh)
> +{
> +  loongarch_init_reloc (eh);
> +  HOOK (eh, reloc_simple_type);
> +
> +  return eh;
> +}
> diff --git a/backends/loongarch_reloc.def b/backends/loongarch_reloc.def
> new file mode 100644
> index ..dd4a6b6d
> --- /dev/null
> +++ b/backends/loongarch_reloc.def
> @@ -0,0 +1,81 @@
> +/* List the relocation types for LoongArch.  -*- C -*-
> +   This file i

Re: [PATCH 10/25] libcpu: Remove the need of NMNES by using enum

[Mark Wielaard]

Hi,

On Fri, 2022-10-21 at 02:25 +0800, Yonggang Luo via Elfutils-devel
wrote:
> Signed-off-by: Yonggang Luo 
> ---
>  libcpu/Makefile.am  |  2 +-
>  libcpu/i386_parse.y | 13 +
>  2 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/libcpu/Makefile.am b/libcpu/Makefile.am
> index 57d0a164..259ed838 100644
> --- a/libcpu/Makefile.am
> +++ b/libcpu/Makefile.am
> @@ -92,7 +92,7 @@ libeu = ../lib/libeu.a
>  i386_lex_CFLAGS = -Wno-unused-label -Wno-unused-function -Wno-sign-
> compare \
> -Wno-implicit-fallthrough
>  i386_parse.o: i386_parse.c i386.mnemonics
> -i386_parse_CFLAGS = -DNMNES="`wc -l < i386.mnemonics`"
> +i386_parse_CFLAGS =
>  i386_lex.o: i386_parse.h
>  i386_gendis_LDADD = $(libeu) -lm $(obstack_LIBS)
>  
> diff --git a/libcpu/i386_parse.y b/libcpu/i386_parse.y
> index d2236d59..5f31484c 100644
> --- a/libcpu/i386_parse.y
> +++ b/libcpu/i386_parse.y
> @@ -1108,9 +1108,14 @@ print_op_fct (const void *nodep, VISIT value,
>  }
>  
>  
> -#if NMNES < 2
> -# error "bogus NMNES value"
> -#endif
> +/* The index can be stored in the instrtab.  */
> +enum
> +  {
> +#define MNE(name) MNE_##name,
> +#include "i386.mnemonics"
> +#undef MNE
> +MNE_COUNT
> +  };

Since almost the same enum is defined in i386_disasm.c, just with
MNE_COUNT = MNE_INVALID, can we define and use them in one place?

>  static void
>  instrtable_out (void)
> @@ -1123,7 +1128,7 @@ instrtable_out (void)
>fprintf (outfile, "#define MNEMONIC_BITS %zu\n",
> best_mnemonic_bits);
>  #else
>fprintf (outfile, "#define MNEMONIC_BITS %ld\n",
> -lrint (ceil (log2 (NMNES;
> +lrint (ceil (log2 (MNE_COUNT;
>  #endif
>fprintf (outfile, "#define SUFFIX_BITS %d\n", nbitsuf);
>for (int i = 0; i < 3; ++i)

Re: [PATCH 11/25] libcpu: Use __asm instead asm that can be recognized by both clang-cl and gcc

[Mark Wielaard]

Hi,

On Fri, 2022-10-21 at 02:25 +0800, Yonggang Luo via Elfutils-devel
wrote:
> Signed-off-by: Yonggang Luo 
> ---
>  libcpu/i386_disasm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libcpu/i386_disasm.c b/libcpu/i386_disasm.c
> index 599d1654..cc75a7b1 100644
> --- a/libcpu/i386_disasm.c
> +++ b/libcpu/i386_disasm.c
> @@ -480,7 +480,7 @@ i386_disasm (Ebl *ebl __attribute__((unused)),
>  
> /* gcc is not clever enough to see the following
> variables
>are not used uninitialized.  */
> -   asm (""
> +   __asm (""
>  : "=mr" (opoff), "=mr" (correct_prefix), "=mr"
> (codep),
>"=mr" (next_curr), "=mr" (len));
>   }

Urgh. Is this really (still) necessary? It is inside an if (0) block.
So it also is never used. Can we just get rid of the whole block?

Thanks,

Mark

Re: [PATCH 12/25] libcpu: Use "#define FCT_mod$64r_m FCT_mod$r_m" is enough and can be recognized by clang-cl on windows in i386_data.h

[Mark Wielaard]

Hi,

On Fri, 2022-10-21 at 02:25 +0800, Yonggang Luo via Elfutils-devel
wrote:
> Signed-off-by: Yonggang Luo 
> ---
>  libcpu/i386_data.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libcpu/i386_data.h b/libcpu/i386_data.h
> index 06356b8a..fe3c4ae1 100644
> --- a/libcpu/i386_data.h
> +++ b/libcpu/i386_data.h
> @@ -1153,7 +1153,7 @@ FCT_mod$64r_m (struct output_data *d)
>return general_mod$r_m (d);
>  }
>  #else
> -static typeof (FCT_mod$r_m) FCT_mod$64r_m __attribute__ ((alias
> ("FCT_mod$r_m")));
> +#define FCT_mod$64r_m FCT_mod$r_m
>  #endif

Thanks, this indeed looks simpler.
Added a ChangeLog entry and pushed as:

commit dab89fba0e84c948fb270e541d1d1313afd2c2c3 (HEAD -> master)
Author: Yonggang Luo 
Date:   Fri Oct 21 02:25:51 2022 +0800

libcpu: Use "#define FCT_mod$64r_m FCT_mod$r_m" in i386_data.h

This is enough and can be recognized by clang-cl on windows

Signed-off-by: Yonggang Luo 

Cheers,

Mark

Re: [PATCH 13/25] libdw: typeof -> __typeof that can be recognized by both clang-cl and gcc

[Mark Wielaard]

Hi,

We seem to use __typeof everywhere except in memory-access.h. So this
seems like an OK change.

Added a ChangeLog entry and pushed as:

commit 78dd3b32edf55fc8bdc6268163d5d743a84b1075
Author: Yonggang Luo 
Date:   Fri Oct 21 02:25:52 2022 +0800

libdw: Change typeof -> __typeof in memory-access.h

Signed-off-by: Yonggang Luo 

Thanks,

Mark

Re: [PATCH 14/25] libdw: check __OPTIMIZE__ in dwarf_whatattr.c and dwarf_whatform.c to match the header

[Mark Wielaard]

Hi,

On Fri, 2022-10-21 at 02:25 +0800, Yonggang Luo via Elfutils-devel
wrote:
> -
> +#ifndef __OPTIMIZE__
>  unsigned int
>  dwarf_whatattr (Dwarf_Attribute *attr)
>  {
>return attr == NULL ? 0 : attr->code;
>  }
> +#endif
> diff --git a/libdw/dwarf_whatform.c b/libdw/dwarf_whatform.c
> index dee29a9f..01a33424 100644
> --- a/libdw/dwarf_whatform.c
> +++ b/libdw/dwarf_whatform.c
> @@ -34,9 +34,10 @@
>  #include 
>  #include "libdwP.h"
>  
> -
> +#ifndef __OPTIMIZE__
>  unsigned int
>  dwarf_whatform (Dwarf_Attribute *attr)
>  {
>return attr == NULL ? 0 : attr->form;
>  }
> +#endif

I don't think this is correct. These functions are defined with extern
inline (if __OPTIMIZE__ is defined). Which means they will not generate
an out-of-line version. But these functions are exported from libdw, so
there must be a real implementation.

So we want to generate code for these functions whether or not
__OPTIMIZE__ is defined.

Cheers,

Mark

☠ Buildbot (GNU Toolchain): elfutils - failed configure (failure) (master)

[builder--- via Elfutils-devel]

A new failure has been detected on builder elfutils-debian-ppc64 while building 
elfutils.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/63/builds/113

Build state: failed configure (failure)
Revision: dab89fba0e84c948fb270e541d1d1313afd2c2c3
Worker: debian-ppc64
Build Reason: (unknown)
Blamelist: Yonggang Luo 

Steps:

- 0: worker_preparation ( success )

- 1: set package name ( success )

- 2: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/113/steps/2/logs/stdio

- 3: autoreconf ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/113/steps/3/logs/stdio

- 4: configure ( failure )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/113/steps/4/logs/stdio

Re: ☠ Buildbot (GNU Toolchain): elfutils - failed configure (failure) (master)

[Mark Wielaard]

Hi,

On Mon, Dec 12, 2022 at 02:01:49PM +, builder--- via Elfutils-devel wrote:
> A new failure has been detected on builder elfutils-debian-ppc64 while 
> building elfutils.
> 
> Full details are available at:
> https://builder.sourceware.org/buildbot/#builders/63/builds/113
> 
> Build state: failed configure (failure)
> Revision: dab89fba0e84c948fb270e541d1d1313afd2c2c3
> Worker: debian-ppc64
> Build Reason: (unknown)
> Blamelist: Yonggang Luo 
> [...] 
> - 4: configure ( failure )
> Logs:
> - stdio: 
> https://builder.sourceware.org/buildbot/#builders/63/builds/113/steps/4/logs/stdio

That looks like a disk space issue:

./config.status: line 1372: printf: write error: No space left on device
config.status: error: in 
`/var/lib/buildbot/workers/wildebeest/elfutils-debian-ppc64/build':
./config.status: line 127: printf: write error: No space left on device

Tom, could you take a look?

Thanks,

Mark

☠ Buildbot (GNU Toolchain): elfutils - failed test (failure) (master)

[builder--- via Elfutils-devel]

A new failure has been detected on builder elfutils-rawhide-x86_64 while 
building elfutils.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/140/builds/74

Build state: failed test (failure)
Revision: 78dd3b32edf55fc8bdc6268163d5d743a84b1075
Worker: bb1-2
Build Reason: (unknown)
Blamelist: Yonggang Luo 

Steps:

- 0: worker_preparation ( success )

- 1: set package name ( success )

- 2: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/2/logs/stdio

- 3: autoreconf ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/3/logs/stdio

- 4: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/4/logs/stdio

- 5: get version ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/5/logs/stdio
- property changes: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/5/logs/property_changes

- 6: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/6/logs/stdio
- warnings (3): 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/6/logs/warnings__3_

- 7: make check ( failure )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/7/logs/stdio
- test-suite.log: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/7/logs/test-suite_log

- 8: make distcheck ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/8/logs/stdio
- test-suite.log: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/8/logs/test-suite_log
- warnings (8): 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/8/logs/warnings__8_

- 9: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/9/logs/stdio

- 10: build bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/10/logs/stdio

- 11: fetch bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/11/logs/stdio

- 12: unpack bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/12/logs/stdio

- 13: pass .bunsen.source.gitname ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/13/logs/stdio

- 14: pass .bunsen.source.gitdescribe ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/14/logs/stdio

- 15: pass .bunsen.source.gitbranch ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/15/logs/stdio

- 16: pass .bunsen.source.gitrepo ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/16/logs/stdio

- 17: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/17/logs/stdio

- 18: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/18/logs/stdio

- 19: make distclean ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/140/builds/74/steps/19/logs/stdio

Re: [PATCH 15/25] lib: Implement error properly even when not HAVE_ERR_H

[Mark Wielaard]

Hi,

On Fri, 2022-10-21 at 02:25 +0800, Yonggang Luo via Elfutils-devel
wrote:
> on win32, there is no err.h
> [...]
> +#else
> +  (void)status;
> +  vfprintf(stderr, format, argp);
> +#endif
>va_end(argp);

That doesn't look like a valid implementation of error, it ignores
errno and doesn't exit when necessary.

Cheers,

Mark

Re: [PATCH 16/25] libeu: Move the implementation of pwrite_retry, write_retry and pread_retry from header to source

[Mark Wielaard]

Hi,

Why is this necessary?

Thanks,

Mark

Re: [PATCH 19/25] libelf: F_GETFD may not predefined with msvc/mingw, guard the usage of it

[Mark Wielaard]

Hi,

On Fri, 2022-10-21 at 02:25 +0800, Yonggang Luo via Elfutils-devel
wrote:
> Signed-off-by: Yonggang Luo 
> ---
>  libelf/elf_begin.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libelf/elf_begin.c b/libelf/elf_begin.c
> index 6d31882e..d867cd6f 100644
> --- a/libelf/elf_begin.c
> +++ b/libelf/elf_begin.c
> @@ -1163,12 +1163,14 @@ elf_begin (int fildes, Elf_Cmd cmd, Elf *ref)
>if (ref != NULL)
>  /* Make sure the descriptor is not suddenly going away.  */
>  rwlock_rdlock (ref->lock);
> +#if defined(F_GETFD)
>else if (unlikely (fcntl (fildes, F_GETFD) == -1 && errno ==
> EBADF))
>  {
>/* We cannot do anything productive without a file
> descriptor.  */
>__libelf_seterrno (ELF_E_INVALID_FILE);
>return NULL;
>  }
> +#endif

If you cannot check validity of fildes using fcntl, then shouldn't you
at least check for fildes >= 0 ?

Cheers,

Mark

Re: ☠ Buildbot (GNU Toolchain): elfutils - failed configure (failure) (master)

[Thomas Fitzsimmons via Elfutils-devel]

Hi Mark,

Mark Wielaard  writes:

> On Mon, Dec 12, 2022 at 02:01:49PM +, builder--- via Elfutils-devel wrote:
>> A new failure has been detected on builder elfutils-debian-ppc64 while 
>> building elfutils.
>> 
>> Full details are available at:
>> https://builder.sourceware.org/buildbot/#builders/63/builds/113
>> 
>> Build state: failed configure (failure)
>> Revision: dab89fba0e84c948fb270e541d1d1313afd2c2c3
>> Worker: debian-ppc64
>> Build Reason: (unknown)
>> Blamelist: Yonggang Luo 
>> [...] 
>> - 4: configure ( failure )
>> Logs:
>> - stdio: 
>> https://builder.sourceware.org/buildbot/#builders/63/builds/113/steps/4/logs/stdio
>
> That looks like a disk space issue:
>
> ./config.status: line 1372: printf: write error: No space left on device
> config.status: error: in 
> `/var/lib/buildbot/workers/wildebeest/elfutils-debian-ppc64/build':
> ./config.status: line 127: printf: write error: No space left on device

Thanks for forwarding.

> Tom, could you take a look?

I didn't see anything particularly deletion-worthy, so I'm going to take
the node down and try to enlarge its root file system.

Thomas

☺ Buildbot (GNU Toolchain): elfutils - build successful (master)

[builder--- via Elfutils-devel]

A restored build has been detected on builder elfutils-debian-ppc64 while 
building elfutils.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/63/builds/115

Build state: build successful
Revision: 78dd3b32edf55fc8bdc6268163d5d743a84b1075
Worker: debian-ppc64
Build Reason: (unknown)
Blamelist: Yonggang Luo 

Steps:

- 0: worker_preparation ( success )

- 1: set package name ( success )

- 2: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/2/logs/stdio

- 3: autoreconf ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/3/logs/stdio

- 4: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/4/logs/stdio

- 5: get version ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/5/logs/stdio
- property changes: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/5/logs/property_changes

- 6: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/6/logs/stdio
- warnings (3): 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/6/logs/warnings__3_

- 7: make check ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/7/logs/stdio
- test-suite.log: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/7/logs/test-suite_log

- 8: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/8/logs/stdio

- 9: build bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/9/logs/stdio

- 10: fetch bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/10/logs/stdio

- 11: unpack bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/11/logs/stdio

- 12: pass .bunsen.source.gitname ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/12/logs/stdio

- 13: pass .bunsen.source.gitdescribe ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/13/logs/stdio

- 14: pass .bunsen.source.gitbranch ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/14/logs/stdio

- 15: pass .bunsen.source.gitrepo ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/15/logs/stdio

- 16: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/16/logs/stdio

- 17: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/17/logs/stdio

- 18: make distclean ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/63/builds/115/steps/18/logs/stdio