Re: nbctfmerge runs for hours on custom i386 kernels

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

> On 03 Mar 2016, at 19:44, Christos Zoulas <christos%astron.com@localhost> wrote:
> 
> In article <5E50530C-0628-46E0-9457-440804E21935%eis.cs.tu-bs.de@localhost>,
> J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote:
>> 
>>> On 02 Mar 2016, at 09:11, Martin Husemann <martin%duskware.de@localhost> wrote:
>>> 
>>> On Tue, Mar 01, 2016 at 05:42:51PM -0600, John D. Baker wrote:
>>>> I have so-far observed this only on i386 and not any of the other
>>>> architectures I build.
>>> 
>>> This is probably caused by ld.elf_so bugs. There is a pullup request
>>> pending to (hopefully) fix this.
>>> 
>>> A simple test (and easy workaround) is to extract usr/libexec/ld.elf_so
>>> from a -current i386 base.tgz and put that on your machine.
>> 
>> For me it is nbctfconvert that creates bad ctf sections on i386 and makes
>> nbctfmerge run for an hour on debug (-g) kernels.
>> 
>> Reverting this
>> 
>> @@ -108,5 +122,6 @@ _dwarf_elf_relocate(Dwarf_Debug dbg, Elf
>>               }
>> 
>> -               if (sh.sh_type != SHT_RELA || sh.sh_size == 0)
>> +               if ((sh.sh_type != SHT_REL && sh.sh_type != SHT_RELA) ||
>> +                    sh.sh_size == 0)
>>                       continue;
>> 
>> from the recent change to
>> external/bsd/elftoolchain/dist/libdwarf/libdwarf_elf_init.c
>> makes my builds happy again.
>> 
>> Looks like the the .debug_info section gets modified to always return
>> the string at offset 0. 
> 
> This is part of this change:
> https://svnweb.freebsd.org/base/head/contrib/elftoolchain/libdwarf/libdwarf_elf_init.c?r1=278593&r2=278611

Yes — and it looks wrong, at least for out i386 objects that use “SHT-REL”
for “.debug_info” where amd64 for example uses “SHT_RELA".

According to the “TIS ELF Specification” page 1-23:

	As shown above, only Elf32_Rela entries contain an explicit addend.
	Entries of type Elf32_Rel store an implicit addend in the location
	to be modified. Depending on the processor architecture, one form
	or the other might be necessary or more convenient. Consequently,
	an implementation for a particular machine may use one form
	exclusively or either form depending on context.

but function libdwarf_elf_init.c::_dwarf_elf_apply_rel_reloc() ignores
this “implicit addend” and treats it as zero.

Take for example file vers.o from a “-g” i386 kernel build:

	RELOCATION RECORDS FOR [.debug_info]:
	OFFSET   TYPE              VALUE 
	00000006 R_386_32          .debug_abbrev
	0000000c R_386_32          .debug_str
	00000011 R_386_32          .debug_str

where .debug_info looks like:

	Contents of section .debug_info:
	0000 b2010000 04000000 00000401 15010000
	0010 01270200 007f0000 00000000 00020106

Here location 0x000c is not zero but this value gets overwritten
with zero.  This leads to all strings to be relocated to zero.

Running “nbctfconvert” with “env CTFCONVERT_DEBUG_LEVEL=9” will
show it in more detail.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)