Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

2017-01-16 Thread Justin Hibbits 
The patch is incorrect, the 'xo' values are off by one bit (inline  
change):



On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote:


Can you try this patch?

Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
@@ -2373,6 +2373,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
 "mftb $RT, $SPR", IIC_SprMFTB>;

+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),


334 should be 167


+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;


462 should be 231.


+
// A pseudo-instruction used to implement the read of the 64-bit  
cycle counter

// on a 32-bit target.
let hasSideEffects = 1, usesCustomInserter = 1 in



I'll have a patch ready for LLVM review within a week or so, including  
some level of scheduling.


- Justin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-16 Thread Mark Millard 
I found some wording relating older-style .got to newer style .got/.got.plt
pair of sections (that need not be near each other). . .

https://sourceware.org/ml/binutils/2004-03/msg00350.html

says that the .got has been split in two: in essence the RELRO part
and the non-RELRO part. Quoting:

> .got.plt section contains the 3 reserved entries plus the GOT entries
> corresponding to the .plt stubs.  The point of separating this from
> .got (where this lived at the beginning of .got, i.e.
> .got : ( *(.got.plt) *(.got) ) in the linker script) is to put the reminder
> of .got to an area which can be write protected after relocation is
> finished because it is constant after relocation is finished.  This is not
> true for .got.plt, which is written to during lazy binding.

That fits with what I've read about the end result that involves .got.plt .

===
Mark Millard
markmi at dsl-only.net

On 2017-Jan-16, at 3:39 PM, Mark Millard  wrote:

> [Correcting a poor wording/interpetatation.]
> 
> On 2017-Jan-16, at 3:28 PM, Mark Millard  wrote:
> 
>> Looking up definitions of the section naming
>> (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . .
>> (Intel context)
>> 
>> 
>> It looks like the RELRO segment (program header information) requires
>> the .got section to be with the .ctors, .dtros, .jcr and such sections:
>> .got is supposed to be inside the RELRO region. ld.lld output was using
>> RELRO. Quoting the description of RELRO:
>> 
>> GNU_RELRO:
>> 
>> This segment indicates the memory region which should be made Read-Only 
>> after relocation is done. This segment usually appears in a dynamic link 
>> library and it contains .ctors, .dtors, .dynamic, .got sections. See 
>> paragraph below.
>> 
>> BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and the 
>> .dynamic just after it.
> 
> That "BUT NOTE" is wrong because both .dynamic and .got were empty and so are 
> not really outside
> the RELRO region: just at the boundary. If they had some positive size then 
> the end of RELRO
> would be after those sections start and would include their content.
> 
>> Showing the objdump output for RELRO:
>> 
>>  RELRO off0x0002 vaddr 0x1002 paddr 
>> 0x1002 align 2**0
>>filesz 0x0138 memsz 0x0138 flags r--
>> 
>> .got.plt and .toc do not go in the RELRO segment.
>> 
>> 
>> Quoting section descriptions. . .
>> 
>> 
>> .rela.plt:
>> 
>> Runtime/Dynamic relocation table.
>> This relocation table is similar to the one in .rela.dyn section; the 
>> difference is this one is for functions, not variables.
>> 
>> The relocation type of entries in this table is R_386_JMP_SLOT or 
>> R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are 
>> inside .got.plt section.
>> 
>> Simply put, this table holds information to relocate entries in .got.plt 
>> section.
>> 
>> 
>> .got:
>> For dynamic binaries, this Global Offset Table holds the addresses of 
>> variables which are relocated upon loading.
>> 
>> [Note: .got was empty because of a lack of global variables. But it
>> was still present.]
>> 
>> 
>> .got.plt:
>> 
>> For dynamic binaries, this Global Offset Table holds the addresses of 
>> functions in dynamic libraries. They are used by trampoline code in .plt 
>> section. If .got.plt section is present, it contains at least three entries, 
>> which have special meanings.
>> 
>> 
>> .toc:
>> 
>> Was not listed. (Likely powerpc64 and/or powerpc specific.)
>> 
>> 
>> 
>> So ld.lld is keeping the .got with the other RELRO materials,
>> as it is supposed to.
>> 
>> And is setting up to allow lazy binding (.got.plt).
>> 
>> It did keep the non-RELRO materials .got.plt and .toc together.
>> But .plt is off by itself, before both the RELRO segment and the
>> .got.plt/.toc pair.
>> 
>> 
>> 
>> As far as I can tell the powerpc and powerpc64 FreeBSD code is
>> not set up for any variation of such things.
>> 
>> It may be that changes are needed to allow RELRO with the .got
>> inside, for example.
>> 
>> It is not obvious that disabling RELRO in ld.lld would change
>> the order and contiguity in memory to what powerpc and powerpc64
>> FreeBSD expect.
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net

On 2017-Jan-16, at 2:32 PM, Mark Millard  wrote:

Here is a more direct list of section addresse rangess from gdb
for ld.lld output:
(I've added comments on the right.)

(gdb) info file
Symbols from "/root/c_tests/a.out".
Local exec file:
`/root/c_tests/a.out', file type elf64-powerpc-freebsd.
Entry point: 0x100300a0
0x1270 - 0x1285 is .interp
0x1288 - 0x12b8 is .note.tag
0x12b8 - 0x12b9 is .rodata
0x12bc - 0x12bc is .eh_frame
0x12c0 - 0x1368 is .dynsym
0x1368 - 0x1376 is .gnu.version

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-16 Thread Mark Millard 
[Correcting a poor wording/interpetatation.]

On 2017-Jan-16, at 3:28 PM, Mark Millard  wrote:

> Looking up definitions of the section naming
> (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . .
> (Intel context)
> 
> 
> It looks like the RELRO segment (program header information) requires
> the .got section to be with the .ctors, .dtros, .jcr and such sections:
> .got is supposed to be inside the RELRO region. ld.lld output was using
> RELRO. Quoting the description of RELRO:
> 
> GNU_RELRO:
> 
> This segment indicates the memory region which should be made Read-Only after 
> relocation is done. This segment usually appears in a dynamic link library 
> and it contains .ctors, .dtors, .dynamic, .got sections. See paragraph below.
> 
> BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and the 
> .dynamic just after it.

That "BUT NOTE" is wrong because both .dynamic and .got were empty and so are 
not really outside
the RELRO region: just at the boundary. If they had some positive size then the 
end of RELRO
would be after those sections start and would include their content.

> Showing the objdump output for RELRO:
> 
>   RELRO off0x0002 vaddr 0x1002 paddr 
> 0x1002 align 2**0
> filesz 0x0138 memsz 0x0138 flags r--
> 
> .got.plt and .toc do not go in the RELRO segment.
> 
> 
> Quoting section descriptions. . .
> 
> 
> .rela.plt:
> 
> Runtime/Dynamic relocation table.
> This relocation table is similar to the one in .rela.dyn section; the 
> difference is this one is for functions, not variables.
> 
> The relocation type of entries in this table is R_386_JMP_SLOT or 
> R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are 
> inside .got.plt section.
> 
> Simply put, this table holds information to relocate entries in .got.plt 
> section.
> 
> 
> .got:
> For dynamic binaries, this Global Offset Table holds the addresses of 
> variables which are relocated upon loading.
> 
> [Note: .got was empty because of a lack of global variables. But it
> was still present.]
> 
> 
> .got.plt:
> 
> For dynamic binaries, this Global Offset Table holds the addresses of 
> functions in dynamic libraries. They are used by trampoline code in .plt 
> section. If .got.plt section is present, it contains at least three entries, 
> which have special meanings.
> 
> 
> .toc:
> 
> Was not listed. (Likely powerpc64 and/or powerpc specific.)
> 
> 
> 
> So ld.lld is keeping the .got with the other RELRO materials,
> as it is supposed to.
> 
> And is setting up to allow lazy binding (.got.plt).
> 
> It did keep the non-RELRO materials .got.plt and .toc together.
> But .plt is off by itself, before both the RELRO segment and the
> .got.plt/.toc pair.
> 
> 
> 
> As far as I can tell the powerpc and powerpc64 FreeBSD code is
> not set up for any variation of such things.
> 
> It may be that changes are needed to allow RELRO with the .got
> inside, for example.
> 
> It is not obvious that disabling RELRO in ld.lld would change
> the order and contiguity in memory to what powerpc and powerpc64
> FreeBSD expect.


===
Mark Millard
markmi at dsl-only.net

On 2017-Jan-16, at 2:32 PM, Mark Millard  wrote:

Here is a more direct list of section addresse rangess from gdb
for ld.lld output:
(I've added comments on the right.)

(gdb) info file
Symbols from "/root/c_tests/a.out".
Local exec file:
`/root/c_tests/a.out', file type elf64-powerpc-freebsd.
Entry point: 0x100300a0
0x1270 - 0x1285 is .interp
0x1288 - 0x12b8 is .note.tag
0x12b8 - 0x12b9 is .rodata
0x12bc - 0x12bc is .eh_frame
0x12c0 - 0x1368 is .dynsym
0x1368 - 0x1376 is .gnu.version
0x1378 - 0x1398 is .gnu.version_r
0x1398 - 0x13d8 is .hash
0x13d8 - 0x141a is .dynstr
0x1420 - 0x1468 is .rela.plt <= note
0x1468 - 0x1474 is .eh_frame_hdr
0x1001 - 0x100104f8 is .text
0x10010500 - 0x1001052c is .init
0x10010530 - 0x10010554 is .fini
0x10010560 - 0x100105c0 is .plt  <= 
NOTE
0x1002 - 0x10020010 is .ctors
0x10020010 - 0x10020020 is .dtors
0x10020020 - 0x10020028 is .jcr
0x10020028 - 0x10020138 is .dynamic
0x10020138 - 0x10020138 is .got  <= 
NOTE
0x1003 - 0x10030019 is .data
0x10030020 - 0x10030050 is .got.plt  <= 
NOTE
0x10030050 -

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-16 Thread Mark Millard 
Looking up definitions of the section naming
(using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . .
(Intel context)


It looks like the RELRO segment (program header information) requires
the .got section to be with the .ctors, .dtros, .jcr and such sections:
.got is supposed to be inside the RELRO region. ld.lld output was using
RELRO. Quoting the description of RELRO:

GNU_RELRO:

This segment indicates the memory region which should be made Read-Only after 
relocation is done. This segment usually appears in a dynamic link library and 
it contains .ctors, .dtors, .dynamic, .got sections. See paragraph below.

BUT NOTE: The ld.lld output has .jcr section in the RELRO segment and the 
.dynamic just after it.


Showing the objdump output for RELRO:

   RELRO off0x0002 vaddr 0x1002 paddr 
0x1002 align 2**0
 filesz 0x0138 memsz 0x0138 flags r--

.got.plt and .toc do not go in the RELRO segment.


Quoting section descriptions. . .


.rela.plt:

Runtime/Dynamic relocation table.
This relocation table is similar to the one in .rela.dyn section; the 
difference is this one is for functions, not variables.

The relocation type of entries in this table is R_386_JMP_SLOT or 
R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are inside 
.got.plt section.

Simply put, this table holds information to relocate entries in .got.plt 
section.


.got:
For dynamic binaries, this Global Offset Table holds the addresses of variables 
which are relocated upon loading.

[Note: .got was empty because of a lack of global variables. But it
was still present.]


.got.plt:

For dynamic binaries, this Global Offset Table holds the addresses of functions 
in dynamic libraries. They are used by trampoline code in .plt section. If 
.got.plt section is present, it contains at least three entries, which have 
special meanings.


.toc:

Was not listed. (Likely powerpc64 and/or powerpc specific.)



So ld.lld is keeping the .got with the other RELRO materials,
as it is supposed to.

And is setting up to allow lazy binding (.got.plt).

It did keep the non-RELRO materials .got.plt and .toc together.
But .plt is off by itself, before both the RELRO segment and the
.got.plt/.toc pair.



As far as I can tell the powerpc and powerpc64 FreeBSD code is
not set up for any variation of such things.

It may be that changes are needed to allow RELRO with the .got
inside, for example.

It is not obvious that disabling RELRO in ld.lld would change
the order and contiguity in memory to what powerpc and powerpc64
FreeBSD expect.


===
Mark Millard
markmi at dsl-only.net

On 2017-Jan-16, at 2:32 PM, Mark Millard  wrote:

Here is a more direct list of section addresse rangess from gdb
for ld.lld output:
(I've added comments on the right.)

(gdb) info file
Symbols from "/root/c_tests/a.out".
Local exec file:
`/root/c_tests/a.out', file type elf64-powerpc-freebsd.
Entry point: 0x100300a0
0x1270 - 0x1285 is .interp
0x1288 - 0x12b8 is .note.tag
0x12b8 - 0x12b9 is .rodata
0x12bc - 0x12bc is .eh_frame
0x12c0 - 0x1368 is .dynsym
0x1368 - 0x1376 is .gnu.version
0x1378 - 0x1398 is .gnu.version_r
0x1398 - 0x13d8 is .hash
0x13d8 - 0x141a is .dynstr
0x1420 - 0x1468 is .rela.plt <= note
0x1468 - 0x1474 is .eh_frame_hdr
0x1001 - 0x100104f8 is .text
0x10010500 - 0x1001052c is .init
0x10010530 - 0x10010554 is .fini
0x10010560 - 0x100105c0 is .plt  <= 
NOTE
0x1002 - 0x10020010 is .ctors
0x10020010 - 0x10020020 is .dtors
0x10020020 - 0x10020028 is .jcr
0x10020028 - 0x10020138 is .dynamic
0x10020138 - 0x10020138 is .got  <= 
NOTE
0x1003 - 0x10030019 is .data
0x10030020 - 0x10030050 is .got.plt  <= 
NOTE
0x10030050 - 0x100300a0 is .toc  <= 
NOTE
0x100300a0 - 0x10030160 is .opd
0x10030160 - 0x10030170 is .bss

It matches the readelf and objdump output reports.

===
Mark Millard
markmi at dsl-only.net

On 2017-Jan-16, at 1:39 PM, Mark Millard  wrote:

> On 2017-Jan-16, at 11:40 AM, Roman Divacky  wrote:
> 
>> I think the TOC (.got + .plt) has to be contiguous in memory. The on-disk
>> layout is not that important.
> 
> I showed the address column that I would expect to accurately reflect 
>

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-16 Thread Mark Millard 
On 2017-Jan-16, at 11:40 AM, Roman Divacky  wrote:

> I think the TOC (.got + .plt) has to be contiguous in memory. The on-disk
> layout is not that important.

I showed the address column that I would expect to accurately reflect addresses
to load to in the process. I also showed the Offset Align which would be 
relative
to whatever base was used (even if different) as far as I can tell.

(Later in repsonse t your question I show what I expect is a sufficient
confirmation.)

Note: objdump and readelf agree (VMA and LMA). Here is the objdump
equivalent:

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
. . .
  9 .rela.plt 0048  1420  1420  0420  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
. . .
 14 .plt  0060  10010560  10010560  00010560  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE
. . .
 19 .got    10020138  10020138  00020138  2**3
  CONTENTS, ALLOC, LOAD, DATA
. . .
 21 .got.plt  0030  10030020  10030020  00030020  2**3
  CONTENTS, ALLOC, LOAD, DATA
 22 .toc  0050  10030050  10030050  00030050  2**3
  CONTENTS, ALLOC, LOAD, DATA
. . .


> Can you check whats the difference of the in-memory TOC between lld and 
> ld.bfd?

gdb reports agreement with the addresses listed by the likes of objdump for
the symbols it reports. There are examples from sections .note.tag, .eh_frame,
.ctors, .dtors, .jcr, .dynamic, .data, .pod, and .bss . None of these sections
move. So I expect the other sections do not move either.

Below I compare objdump symbols reporting to gdb reporting of what symbol is
at an address, at least one address for each one of those sections with a
symbol.

Here is what objdump shows for assigned symbols (sorted):
(I've inserted some comments about some other sections
that have no symbols based on the addresses from objdump
and readelf.)

1288 l O .note.tag  0018  abitag
12a0 l O .note.tag  0018  
crt_noinit_tag
12bb l O .eh_frame  0004  
__FRAME_END__
.rela.plt fits between here: 1420 (start)
.plt fits between here : 10010560 (start)
1002 l O .ctors 0008  __CTOR_LIST__
10020008 l O .ctors 0008  __CTOR_END__
10020010 l O .dtors 0008  __DTOR_LIST__
10020018 l O .dtors 0008  __DTOR_END__
10020020 l O .jcr     __JCR_LIST__
10020020 l O .jcr   0008  __JCR_END__
10020028 l   .dynamic     .hidden 
_DYNAMIC
.got fits between here : 10020138 (start and end: size zero)
1003 g O .data  0008  __progname
10030008 l O .data  0008  .hidden 
__dso_handle
10030010 l O .data  0008  
__do_global_dtors_aux.p
10030018 l O .data  0001  
__do_global_dtors_aux.completed
.got.plt fits between here : 10030020 (start)
.toc fits between here : 10030050 (start)
100300a0 g F .opd   0264  _start
100300b8 l F .opd   00d0  finalizer
100300d0 l F .opd     .hidden _init
100300e8 l F .opd     .hidden _fini
10030100 l F .opd   00a4  
__do_global_dtors_aux
10030118 l F .opd   007c  frame_dummy
10030130 g F .opd   001c  main
10030148 l F .opd   0088  
__do_global_ctors_aux
10030160 g O .bss   0008  __ps_strings
10030168 g O .bss   0008  environ
10030170 g   *ABS*    _end

Examples of gdb reporting symbol information for some of those addresses:

(gdb) info symbol 0x1288
abitag in section .note.tag
(gdb) info symbol 0x12a0
crt_noinit_tag in section .note.tag
(gdb) info symbol 0x12a4
crt_noinit_tag + 4 in section .note.tag
(gdb) info symbol 0x10020008
__CTOR_END__ in section .ctors
(gdb) info symbol 0x10020010
__DTOR_LIST__ in section .dtors
(gdb) info symbol 0x10020020
__JCR_END__ in section .jcr
(gdb) info symbol 0x10020028
_DYNAMIC in section .dynamic
(gdb) info symbol 0x10030010
__do_global_dtors_aux.p in section .data
(gdb) info symbol 0x100300a0
_start in section .opd
(gdb) info symbol

[Bug 216117] clang 4.0.0 crashes trying to build lld on i386

2017-01-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117

--- Comment #6 from commit-h...@freebsd.org ---
A commit references this bug:

Author: dim
Date: Mon Jan 16 19:53:19 UTC 2017
New revision: 312308
URL: https://svnweb.freebsd.org/changeset/base/312308

Log:
  Pull in r292133 from upstream llvm trunk (by Hal Finkel):

Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith

When transferring affected values in the cache from an old value,
identified by the value of the current callback, to the specified new
value we might need to insert a new entry into the DenseMap which
constitutes the cache. Doing so might delete the current callback
object. Move the copying logic into a new function, a member of the
assumption cache itself, so that we don't run into UB should the
callback handle itself be removed mid-copy.

Differential Revision: https://reviews.llvm.org/D28749

  This should fix crashes when building lld (as part of the llvmXY ports).

  Reported by:  jbeich
  PR:   216117

Changes:
  projects/clang400-import/contrib/llvm/include/llvm/Analysis/AssumptionCache.h
  projects/clang400-import/contrib/llvm/lib/Analysis/AssumptionCache.cpp

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-16 Thread Roman Divacky 
Mark,

I think the TOC (.got + .plt) has to be contiguous in memory. The on-disk
layout is not that important.

Can you check whats the difference of the in-memory TOC between lld and ld.bfd?

Thanks, Roman

On Fri, Jan 13, 2017 at 02:07:00PM -0800, Mark Millard wrote:
> Just an FYI:
> 
> elfdump -a (from -r311950) does not dump .plt or .got.plt or .toc :
> 
> # elfdump -a a.out | egrep "(got|toc|plt|:$)" | more
> elf header:
> program header:
> section header:
> sh_name: .rela.plt
> sh_name: .plt
> sh_name: .got
> sh_name: .got.plt
> sh_name: .toc
> interp:
> symbol table (.dynsym):
> relocation with addend (.rela.plt):
> dynamic:
> global offset table:
> symbol table (.symtab):
> 
> (The "global offset table" was empty but its title was listed.)
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2017-Jan-12, at 5:58 PM, Mark Millard  wrote:
> 
> On 2017-Jan-12, at 11:22 AM, Roman Divacky  wrote:
> 
> > Can you check if the TOC is correct? LLD assumes this:
> > 
> > static uint64_t PPC64TocOffset = 0x8000;
> > 
> > uint64_t getPPC64TocBase() {
> > // The TOC consists of sections .got, .toc, .tocbss, .plt in that order. The
> > // TOC starts where the first of these sections starts. We always create a
> > // .got when we see a relocation that uses it, so for us the start is always
> > // the .got.
> > uint64_t TocVA = In::Got->getVA();
> > 
> > // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000
> > // thus permitting a full 64 Kbytes segment. Note that the glibc startup
> > // code (crt1.o) assumes that you can get from the TOC base to the
> > // start of the .toc section with only a single (signed) 16-bit relocation.
> > return TocVA + PPC64TocOffset;
> > }
> 
> [I warn that I'm outside familiar territory here.]
> 
> If I understand the 1st comment right the following does not look
> like a match for -fuse-dl=lld (readelf -a output):
> 
> Section Headers:
>  [Nr] Name  Type Address   Offset
>   Size  EntSize  Flags  Link  Info  Align
>  [ 0]   NULL   
>        0 0 0
> . . .
>  [10] .rela.plt RELA 1420  0420
>   0048  0018   A   5 0 8
> . . .
>  [15] .plt  PROGBITS 10010560  00010560
>   0060    AX   0 0 16
> . . .
>  [20] .got  PROGBITS 10020138  00020138
>       WA   0 0 8
> . . .
>  [22] .got.plt  PROGBITS 10030020  00030020
>   0030    WA   0 0 8
> . . .
>  [23] .toc  PROGBITS 10030050  00030050
>   0050    WA   0 0 8
> 
> Possibly contributing reasons:
> 
> A) .got is not "first" of the 4 sections (by Address or by [Nr]).
>   (.got is listed as zero size as well)
> B) There is no reference to .got.plt in the comment.
> C) .got and .toc have .got.plt and other things between
>   -- and .got and .got.plt have stuff between.
> D) There is no .tocbss at all (guess: optional so possibly okay).
> E) .plt is before .got by address and by [Nr]
>   (it is als not next to .got or .got.plt or .toc).
> F) There is no reference to .got.plt in the comment.
> G) In general there are other things between the sections
>   making them spread over a wider address range.
> 
> [I guess that .rela.plt does not matter but I showed it
> in case I'm wrong.]
> 
> Another potential issue is .plt being PROGBITS instead of
> NOBITS (see below). Related is AX flags above vs. WA
> flags below being a potential issue.
> 
> 
> By contrast for -fuse-dl-bfd I see:
> 
> Section Headers:
>  [Nr] Name  Type Address   Offset
>   Size  EntSize  Flags  Link  Info  Align
>  [ 0]   NULL   
>        0 0 0
> . . .
>  [ 8] .rela.plt RELA 1370  0370
>   0048  0018   A   422 8
> . . .
>  [21] .got  PROGBITS 10010c48  0c48
>   0058  0008  WA   0 0 8
>  [22] .plt  NOBITS   10010ca0  0ca0
>   0060  0018  WA   0 0 8
> 
> So no .toc or .tocbase sections.
> 
> But .got and .plt are next to each other with .got first
> (by address and by [Nr]). This would fit the comments if
> .toc and .tocbss are optional --and apparently they are.
> 
> So my guess is that -fuse-dl-bfd looks to be as expected,
> unlike -fuse-dl=lld .
> 
> 
> > Perhaps thats not true on FreeBSD? Especially the hardcoded constant seems 
>