Bug 195561 - [exp-run] use elftoolchain tools: src.conf WITH_ELFTOOLCHAIN_TOOLS=yes
Summary: [exp-run] use elftoolchain tools: src.conf WITH_ELFTOOLCHAIN_TOOLS=yes
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ed Maste
URL:
Keywords:
Depends on: 195653 196038 196107
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-01 20:26 UTC by Ed Maste
Modified: 2015-01-12 19:14 UTC (History)
1 user (show)

See Also:
antoine: exp-run?


Attachments
ktrace output for testprog/addr2line (45.62 KB, text/plain)
2015-01-04 17:05 UTC, Antoine Brodin
no flags Details
ktrace output for testprog/gnu addr2line (147.75 KB, text/plain)
2015-01-04 17:11 UTC, Antoine Brodin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2014-12-01 20:26:05 UTC
As of r275373 I added build infrastructure for building and using a number of ELF toolchain tools instead of GNU binutils:

https://svnweb.freebsd.org/base?view=revision&revision=275373

It is enabled by adding WITH_ELFTOOLCHAIN_TOOLS=yes to /etc/src.conf. I'd like an exp-run with this setting. (Or if there is some exp-run tooling that makes it easier to test a patch, I will attach one to move ELFTOOLCHAIN_TOOLS to a default yes option.)
Comment 1 Antoine Brodin freebsd_committer 2014-12-02 21:56:18 UTC
Take for exp-run
Comment 2 Antoine Brodin freebsd_committer 2014-12-02 23:29:56 UTC
There is a problem,  i can't login in an i386 jail created with WITH_ELFTOOLCHAIN_TOOLS=yes
Comment 3 Antoine Brodin freebsd_committer 2014-12-02 23:45:20 UTC
something looks really wrong on i386:

pid 38148 (make), uid 0: exited on signal 11 (core dumped)
pid 38408 (make), uid 0: exited on signal 11 (core dumped)
pid 38724 (make), uid 0: exited on signal 11 (core dumped)
pid 39396 (csh), uid 0: exited on signal 11 (core dumped)
pid 40254 (make), uid 0: exited on signal 11 (core dumped)
pid 40319 (csh), uid 0: exited on signal 11 (core dumped)
pid 42098 (make), uid 0: exited on signal 11 (core dumped)
pid 43351 (csh), uid 0: exited on signal 11 (core dumped)
pid 53971 (csh), uid 0: exited on signal 11 (core dumped)
pid 54239 (csh), uid 0: exited on signal 11 (core dumped)

I have the csh.core if you want
Comment 4 Ed Maste freebsd_committer 2014-12-03 01:01:44 UTC
To confirm, this is building an i386 jail on an amd64 buildhost, with TARGET=i386?

Is it feasible to check the amd64 case by itself while I figure out what's going on there.
Comment 5 Antoine Brodin freebsd_committer 2014-12-03 07:27:48 UTC
Yes,  TARGET=i386 TARGET_ARCH=i386
/bin/sh from the jail runs,  /bin/csh or /usr/bin/make do a core dump
Comment 6 Antoine Brodin freebsd_committer 2014-12-03 07:55:03 UTC
On amd64 it's the same, make dumps core.
Comment 7 Antoine Brodin freebsd_committer 2014-12-03 07:55:22 UTC
Back to submitter
Comment 8 Antoine Brodin freebsd_committer 2014-12-03 13:28:19 UTC
I can provide the core-dumping make for both i386 and amd64 if needed
Comment 9 Ed Maste freebsd_committer 2014-12-15 18:20:39 UTC
The issue affecting make/csh should be fixed in r275810.

Can you try the exp-run again?
Comment 10 Antoine Brodin freebsd_committer 2014-12-15 23:17:45 UTC
Take for exp-run
Comment 11 Antoine Brodin freebsd_committer 2014-12-16 18:14:17 UTC
Exp-run results:

http://package18.nyi.freebsd.org/build.html?mastername=head-amd64-PR195561-default&build=2014-12-15_23h48m44s


6 new failures on amd64:

+ {"origin"=>"lang/gcc48", "pkgname"=>"gcc48-4.8.4.s20141120", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"lang/gcc49", "pkgname"=>"gcc49-4.9.3.s20141126", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"lang/gcc5", "pkgname"=>"gcc5-5.0.s20141130", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"multimedia/ffmpeg", "pkgname"=>"ffmpeg-2.3.5_4,1", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"multimedia/ffmpeg24", "pkgname"=>"ffmpeg24-2.4.3_4", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"multimedia/libav", "pkgname"=>"libav-10.2_7", "phase"=>"build", "errortype"=>"linker_error"}

Failure logs:

http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/gcc48-4.8.4.s20141120.log
http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/gcc49-4.9.3.s20141126.log
http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/gcc5-5.0.s20141130.log
http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/ffmpeg-2.3.5_4,1.log
http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/ffmpeg24-2.4.3_4.log
http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/libav-10.2_7.log

In ffmpeg/libav,  the ranlib and ar warning are new
Comment 12 Ed Maste freebsd_committer 2014-12-16 18:34:56 UTC
gcc failures are stage 2 / stage 3 comparison failure of the form

> Comparing stages 2 and 3
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!
> gcc/tree-vect-data-refs.o differs
> gcc/asan.o differs
Comment 13 Antoine Brodin freebsd_committer 2014-12-16 18:54:14 UTC
For multimedia/ffmpeg:

during successful build (with gnu tools):

# file work/ffmpeg-2.3.5/libswscale/x86/*.o
work/ffmpeg-2.3.5/libswscale/x86/input.o:   ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
work/ffmpeg-2.3.5/libswscale/x86/output.o:  ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
work/ffmpeg-2.3.5/libswscale/x86/rgb2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
work/ffmpeg-2.3.5/libswscale/x86/scale.o:   ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
work/ffmpeg-2.3.5/libswscale/x86/swscale.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
work/ffmpeg-2.3.5/libswscale/x86/yuv2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

during failing build (with elftoolchain):

# file work/ffmpeg-2.3.5/libswscale/x86/*.o
work/ffmpeg-2.3.5/libswscale/x86/input.o:   ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
work/ffmpeg-2.3.5/libswscale/x86/output.o:  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
work/ffmpeg-2.3.5/libswscale/x86/rgb2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
work/ffmpeg-2.3.5/libswscale/x86/scale.o:   ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
work/ffmpeg-2.3.5/libswscale/x86/swscale.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
work/ffmpeg-2.3.5/libswscale/x86/yuv2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
Comment 14 Ed Maste freebsd_committer 2014-12-16 19:14:52 UTC
From ffmpeg's configure script:

> # add some strip flags
> # -wN '..@*' is more selective than -x, but not available everywhere.
> check_stripflags -wN \'..@*\' || check_stripflags -x                            

Both elftoolchain strip and binutils strip accept -w.

With a trivial foo.o and strip without arguments (strip foo.o) binutils and elftoolchain strip produce identical output, with debug info, symtab and strtab stripped.

With "strip -wN \'..@*\' foo.o" the binutils .o has the same content as the original (except that the , while elftoolchain strips the debug info, symtab and strtab.
Comment 15 Antoine Brodin freebsd_committer 2014-12-16 19:51:14 UTC
For gcc:

# readelf -S build/stage2-gcc/cc1plus-checksum.o build/stage3-gcc/cc1plus-checksum.o

File: build/stage2-gcc/cc1plus-checksum.o
There are 10 section headers, starting at offset 0xe0:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000000  0000000000000000  AX       0     0     1
  [ 2] .data             PROGBITS         0000000000000000  00000040
       0000000000000000  0000000000000000  WA       0     0     1
  [ 3] .bss              NOBITS           0000000000000000  00000040
       0000000000000000  0000000000000000  WA       0     0     1
  [ 4] .rodata           PROGBITS         0000000000000000  00000040
       0000000000000010  0000000000000000   A       0     0     16
  [ 5] .comment          PROGBITS         0000000000000000  00000050
       000000000000003d  0000000000000001  MS       0     0     1
  [ 6] .note.GNU-stack   PROGBITS         0000000000000000  0000008d
       0000000000000000  0000000000000000           0     0     1
  [ 7] .shstrtab         STRTAB           0000000000000000  0000008d
       000000000000004d  0000000000000000           0     0     1
  [ 8] .symtab           SYMTAB           0000000000000000  00000360
       00000000000000d8  0000000000000018           9     8     8
  [ 9] .strtab           STRTAB           0000000000000000  00000438
       0000000000000028  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

File: build/stage3-gcc/cc1plus-checksum.o
There are 17 section headers, starting at offset 0x2080:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000000  0000000000000000  AX       0     0     1
  [ 2] .data             PROGBITS         0000000000000000  00000040
       0000000000000000  0000000000000000  WA       0     0     1
  [ 3] .bss              NOBITS           0000000000000000  00000040
       0000000000000000  0000000000000000  WA       0     0     1
  [ 4] .rodata           PROGBITS         0000000000000000  00000040
       0000000000000010  0000000000000000   A       0     0     16
  [ 5] .debug_info       PROGBITS         0000000000000000  00000050
       00000000000012be  0000000000000000           0     0     1
  [ 6] .rela.debug_info  RELA             0000000000000000  00002638
       00000000000013e0  0000000000000018          15     5     8
  [ 7] .debug_abbrev     PROGBITS         0000000000000000  0000130e
       00000000000001e2  0000000000000000           0     0     1
  [ 8] .debug_aranges    PROGBITS         0000000000000000  000014f0
       0000000000000020  0000000000000000           0     0     1
  [ 9] .rela.debug_arang RELA             0000000000000000  00003a18
       0000000000000018  0000000000000018          15     8     8
  [10] .debug_line       PROGBITS         0000000000000000  00001510
       0000000000000225  0000000000000000           0     0     1
  [11] .debug_str        PROGBITS         0000000000000000  00001735
       0000000000000873  0000000000000001  MS       0     0     1
  [12] .comment          PROGBITS         0000000000000000  00001fa8
       000000000000003d  0000000000000001  MS       0     0     1
  [13] .note.GNU-stack   PROGBITS         0000000000000000  00001fe5
       0000000000000000  0000000000000000           0     0     1
  [14] .shstrtab         STRTAB           0000000000000000  00001fe5
       0000000000000097  0000000000000000           0     0     1
  [15] .symtab           SYMTAB           0000000000000000  000024c0
       0000000000000150  0000000000000018          16    13     8
  [16] .strtab           STRTAB           0000000000000000  00002610
       0000000000000028  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)
Comment 16 Ed Maste freebsd_committer 2014-12-16 21:35:05 UTC
PR 196038 is (part of?) the reason the ffmpeg ports fail. After it's fixed I will try the gcc port locally to continue the investigation.
Comment 17 Ed Maste freebsd_committer 2014-12-18 14:03:38 UTC
> readelf -S build/stage2-gcc/cc1plus-checksum.o build/stage3-gcc/cc1plus-checksum.o

It looks like the debug info in stage 3 and but not in stage 2 is an expected part of GCC's build - https://gcc.gnu.org/install/build.html (bootstrap-debug option)

GCC uses a contrib/compare-debug script to strip the stage 2 and stage 3 .o files before comparing them (and allows for some other differences too).

I'm having trouble tracking down the comparison failure though, and I'm not sure where /usr/bin/strip is being used vs. /usr/local/x86_64-portbld-freebsd11.0/bin/strip. I see the binutils portbld strip being picked up by configure.
Comment 19 Antoine Brodin freebsd_committer 2014-12-18 19:00:49 UTC
for gcc5 on amd64:

The differences seem to be in the Info in the GROUP sections.

There seems to be a difference of 7 between the Info in the GROUP sections of stage2 and stage3  (tested on 4 or 5 stripped objects)

For instance:

# readelf -S stage2-gcc/expmed.o.stripped
There are 20 section headers, starting at offset 0xebf8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .group            GROUP            0000000000000000  00000040
       000000000000000c  0000000000000004           0   216     4
  [ 2] .text             PROGBITS         0000000000000000  00000050
       000000000000cc47  0000000000000000  AX       0     0     16
  [ 3] .rela.text        RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0     2     8
  [ 4] .data             PROGBITS         0000000000000000  0000cc98
       000000000000000c  0000000000000000  WA       0     0     8
  [ 5] .rela.data        RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0     4     8
  [ 6] .bss              NOBITS           0000000000000000  0000ccc0
       0000000000019940  0000000000000000  WA       0     0     64
  [ 7] .text.unlikely    PROGBITS         0000000000000000  0000ccc0
       000000000000007f  0000000000000000  AX       0     0     2
  [ 8] .rela.text.unlike RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0     7     8
  [ 9] .rodata.str1.8    PROGBITS         0000000000000000  0000cd40
       00000000000000e9  0000000000000001 AMS       0     0     8
  [10] .rodata.str1.1    PROGBITS         0000000000000000  0000ce29
       000000000000000f  0000000000000001 AMS       0     0     1
  [11] .rodata           PROGBITS         0000000000000000  0000ce40
       00000000000005d2  0000000000000000   A       0     0     16
  [12] .rela.rodata      RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0    11     8
  [13] .text.unlikely._Z PROGBITS         0000000000000000  0000d412
       0000000000000000  0000000000000000 AXG       0     0     2
  [14] .text._ZN16generi PROGBITS         0000000000000000  0000d420
       00000000000000a7  0000000000000000 AXG       0     0     16
  [15] .comment          PROGBITS         0000000000000000  0000d4c7
       000000000000003f  0000000000000001  MS       0     0     1
  [16] .note.GNU-stack   PROGBITS         0000000000000000  0000d506
       0000000000000000  0000000000000000           0     0     1
  [17] .eh_frame         PROGBITS         0000000000000000  0000d508
       00000000000015b0  0000000000000000   A       0     0     8
  [18] .rela.eh_frame    RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0    17     8
  [19] .shstrtab         STRTAB           0000000000000000  0000eab8
       000000000000013f  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


-> Info in .group section is 216


# readelf -S stage3-gcc/expmed.o.stripped
There are 20 section headers, starting at offset 0xebf8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .group            GROUP            0000000000000000  00000040
       000000000000000c  0000000000000004           0   223     4
  [ 2] .text             PROGBITS         0000000000000000  00000050
       000000000000cc47  0000000000000000  AX       0     0     16
  [ 3] .rela.text        RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0     2     8
  [ 4] .data             PROGBITS         0000000000000000  0000cc98
       000000000000000c  0000000000000000  WA       0     0     8
  [ 5] .rela.data        RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0     4     8
  [ 6] .bss              NOBITS           0000000000000000  0000ccc0
       0000000000019940  0000000000000000  WA       0     0     64
  [ 7] .text.unlikely    PROGBITS         0000000000000000  0000ccc0
       000000000000007f  0000000000000000  AX       0     0     2
  [ 8] .rela.text.unlike RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0     7     8
  [ 9] .rodata.str1.8    PROGBITS         0000000000000000  0000cd40
       00000000000000e9  0000000000000001 AMS       0     0     8
  [10] .rodata.str1.1    PROGBITS         0000000000000000  0000ce29
       000000000000000f  0000000000000001 AMS       0     0     1
  [11] .rodata           PROGBITS         0000000000000000  0000ce40
       00000000000005d2  0000000000000000   A       0     0     16
  [12] .rela.rodata      RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0    11     8
  [13] .text.unlikely._Z PROGBITS         0000000000000000  0000d412
       0000000000000000  0000000000000000 AXG       0     0     2
  [14] .text._ZN16generi PROGBITS         0000000000000000  0000d420
       00000000000000a7  0000000000000000 AXG       0     0     16
  [15] .comment          PROGBITS         0000000000000000  0000d4c7
       000000000000003f  0000000000000001  MS       0     0     1
  [16] .note.GNU-stack   PROGBITS         0000000000000000  0000d506
       0000000000000000  0000000000000000           0     0     1
  [17] .eh_frame         PROGBITS         0000000000000000  0000d508
       00000000000015b0  0000000000000000   A       0     0     8
  [18] .rela.eh_frame    RELA             0000000000000000  0000f0f8
       0000000000000000  0000000000000018           0    17     8
  [19] .shstrtab         STRTAB           0000000000000000  0000eab8
       000000000000013f  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


-> Info in .group section is 223
Comment 20 Antoine Brodin freebsd_committer 2014-12-18 22:25:47 UTC
8 out of the 12 strip tests from the binutils testsuite are about section group:

strip-1.d:#name: strip with section group 1
strip-2.d:#name: strip with section group 2
strip-4.d:#name: strip with section group 4
strip-5.d:#name: strip with section group 5
strip-6.d:#name: strip with section group 6
strip-7.d:#name: strip with section group 7
strip-8.d:#name: strip with section group 8
strip-9.d:#name: strip with section group 9

I can put the result I have with gnu strip versus elftoolchain strip somewhere,  for instance there are some readelf errors with objects stripped by elftoolchain strip:  "readelf: Error: Bad sh_link in group section `.group'"

This test crashes strip from elftoolchain too:

strip-3.d:#name: strip empty file
Comment 21 Ed Maste freebsd_committer 2014-12-18 22:50:46 UTC
The crash on empty .o is reported here: https://sourceforge.net/p/elftoolchain/tickets/463/
Comment 22 Antoine Brodin freebsd_committer 2014-12-18 23:12:54 UTC
I put the diff between gnu and elftoolchain strip at:

http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-18_18h05m16s/logs/errors/group-section.txt
Comment 23 Antoine Brodin freebsd_committer 2014-12-19 22:35:11 UTC
(In reply to Antoine Brodin from comment #18)
> There is also 1 link failure:
> 
> http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-
> 17_20h57m47s/logs/errors/caudium14-1.4.18.7.8.866.log

You can ignore this one,  it's broken without elftoolchain too.
Comment 24 Ed Maste freebsd_committer 2014-12-24 05:07:28 UTC
I have an elftoolchain update in the projects/elftoolchain-update-r3130 branch, which should improve group handling and fix issues found in the i386 exp-run.
Comment 25 Antoine Brodin freebsd_committer 2014-12-28 09:42:58 UTC
Exp-run results on i386:

http://pb2.nyi.freebsd.org/build.html?mastername=head-i386-PR195561-default&build=2014-12-27_17h54m19s

7 new failures:

+ {"origin"=>"devel/etcd", "pkgname"=>"coreos-etcd-0.4.6", "phase"=>"stage", "errortype"=>"???"}
+ {"origin"=>"devel/etcdctl", "pkgname"=>"coreos-etcdctl-0.4.6", "phase"=>"stage", "errortype"=>"???"}
+ {"origin"=>"finance/fixc", "pkgname"=>"fixc-1.0", "phase"=>"stage", "errortype"=>"???"}
+ {"origin"=>"misc/exercism", "pkgname"=>"exercism-1.7.1", "phase"=>"stage", "errortype"=>"???"}
+ {"origin"=>"security/meek", "pkgname"=>"meek-0.9", "phase"=>"stage", "errortype"=>"???"}
+ {"origin"=>"security/pond", "pkgname"=>"pond-20140824_1", "phase"=>"stage", "errortype"=>"???"}
+ {"origin"=>"sysutils/logstash-forwarder", "pkgname"=>"logstash-forwarder-0.3.1.20140829", "phase"=>"stage", "errortype"=>"???"

Failure logs:

http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/coreos-etcd-0.4.6.log
http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/coreos-etcdctl-0.4.6.log
http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/fixc-1.0.log
http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/exercism-1.7.1.log
http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/meek-0.9.log
http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/pond-20140824_1.log
http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/logstash-forwarder-0.3.1.20140829.log
Comment 26 Antoine Brodin freebsd_committer 2014-12-28 13:48:48 UTC
Exp-run results on amd64:

http://pb2.nyi.freebsd.org/build.html?mastername=head-amd64-PR195561-default&build=2014-12-28_09h50m55s

0 new failure
Comment 27 Ed Maste freebsd_committer 2014-12-29 21:09:23 UTC
(In reply to Antoine Brodin from comment #25)
> Exp-run results on i386:
> 
> http://pb2.nyi.freebsd.org/build.html?mastername=head-i386-PR195561-
> default&build=2014-12-27_17h54m19s
> 
> 7 new failures:

I reported the i386 failures in upstream elftoolchain ticket 465; it appears they all have the same cause.
https://sourceforge.net/p/elftoolchain/tickets/465/

Should be fixed by upstream revs 3131-3134 (I'm up to 3130 in FreeBSD head):
https://sourceforge.net/p/elftoolchain/code/3131
https://sourceforge.net/p/elftoolchain/code/3132
https://sourceforge.net/p/elftoolchain/code/3133
https://sourceforge.net/p/elftoolchain/code/3134

I will do another import soon.
Comment 28 Ed Maste freebsd_committer 2014-12-30 03:29:24 UTC
Updated to upstream r3136 in FreeBSD r276398. I believe this should address all of the issues found by the exp-run.

Thanks again for all of the effort on this!
Comment 29 Antoine Brodin freebsd_committer 2014-12-30 18:57:51 UTC
There is a regression,  installworld fails on i386:

===> rescue/rescue (install)
install -N /zpoudriere/jails/head-i386-PR195561/usr/src/etc -s -o root -g wheel -m 555   rescue /zpoudriere/jails/head-i386-PR195561/rescue/rescue
strip: 692 gelf_getshdr() failed: Invalid argument
install: strip command strip failed on /zpoudriere/jails/head-i386-PR195561/rescue/rescue
*** Error code 70
Comment 30 Ed Maste freebsd_committer 2014-12-30 22:39:38 UTC
Should be fixed as of r276427
Comment 31 Antoine Brodin freebsd_committer 2015-01-04 12:17:03 UTC
- On both amd64 and i386,  I have a hang during french/aster build.

See log at:
http://pb2.nyi.freebsd.org/data/head-amd64-PR195561-default/2015-01-03_11h00m24s/logs/errors/fr-aster-11.6.0.1_3.log

It hangs during /usr/bin/addr2line invocation.
I searched a bit and found that this comes from libgfortran.so
You can find the source of backtrace() in gcc-4.8.4/libgfortran/runtime/backtrace.c


- On i386,  java seems to have more memory failures with elftoolchain than without,  I have to relaunch an incremental build for the following ports,  they always fail with memory failure (heap space) during first run:

java/eclipse
java/jboss71
misc/freebsd-doc-de
misc/freebsd-doc-el
misc/freebsd-doc-fr
misc/freebsd-doc-hu
misc/freebsd-doc-it
misc/freebsd-doc-mn
misc/freebsd-doc-nl
misc/freebsd-doc-pl
misc/freebsd-doc-ru
misc/freebsd-doc-zh_cn
misc/freebsd-doc-zh_tw

examples of failures:
http://package18.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-03_11h00m34s/logs/errors/eclipse-4.3.2_3.log
http://package18.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-03_11h00m34s/logs/errors/fr-freebsd-doc-46070,1.log
http://package18.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-03_11h00m34s/logs/errors/jboss71-7.1.3.log
Comment 32 Antoine Brodin freebsd_committer 2015-01-04 17:05:56 UTC
Created attachment 151333 [details]
ktrace output for testprog/addr2line
Comment 33 Antoine Brodin freebsd_committer 2015-01-04 17:11:39 UTC
Created attachment 151334 [details]
ktrace output for testprog/gnu addr2line
Comment 34 Antoine Brodin freebsd_committer 2015-01-04 19:37:19 UTC
You can ignore the java memory failures,  I managed to get them with MALLOC_PRODUCTION=yes and without WITH_ELFTOOLCHAIN_TOOLS
Comment 35 commit-hook freebsd_committer 2015-01-05 04:57:11 UTC
A commit references this bug:

Author: emaste
Date: Mon Jan  5 04:56:39 UTC 2015
New revision: 276689
URL: https://svnweb.freebsd.org/changeset/base/276689

Log:
  addr2line: fflush output after each address lookup

  Certain tools spawn addr2line and pass addresses one at a time for
  resolution.

  PR:		195561
  Reported by:	antoine
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/contrib/elftoolchain/addr2line/addr2line.c
Comment 36 Antoine Brodin freebsd_committer 2015-01-05 11:42:06 UTC
I confirm that french/aster build successfully now.
http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-05_09h27m28s/logs/fr-aster-11.6.0.1_3.log
Comment 37 Antoine Brodin freebsd_committer 2015-01-06 15:23:09 UTC
Looks good, no new failure.