Subject: ddb line number support for ELF
To: None <tech-kern@netbsd.org>
From: John Hawkinson <jhawk@mit.edu>
List: tech-kern
Date: 07/25/2000 01:30:51
One of the things I'd hoped to have ready for 1.5 was support for line
numbers in DDB for ELF, since otherwise 1.5 would be a step backward
for the kernel debugger, as a.out supports line numbers.

In examining this, it seems that debugging data is split across two
tables, .stab and .stabstr. Unfortunately, it seems that the i386 boot
loader does not load .stab, only .stabstr.

biosboot prints:

3956065+391512+319844 [23516+80+246112+20125] = 0x4e7920

which is:

text+rodata+pad(12), data, bss+pad(8), [stabstr, shstrtab, symtab, strtab]

Sections are actually:

SECTION .text offset 4096 size 3069748 type 1		PROGBITS
SECTION .rodata offset 3073856 size 886305 type 1	PROGBITS
SECTION .data offset 3960192 size 391512 type 1		PROGBITS
SECTION .bss offset 4351712 size 319836 type 8		NOBITS
SECTION .stab offset 4351712 size 9948 type 1		PROGBITS
SECTION .stabstr offset 532 size 23516 type 3		STRTAB
SECTION .note offset 4385176 size 18160 type 7		NOTE
SECTION .ident offset 4403336 size 819 type 1		PROGBITS
SECTION .shstrtab offset 24048 size 80 type 3		STRTAB
SECTION .symtab offset 24128 size 246112 type 2		SYMTAB
SECTION .strtab offset 270240 size 201025 type 3	STRTAB

It appears the culprit is that libsa/loadfile.c uses the following
algorithm:


	a) Load all program sections for which their program header
	is marked PT_LOAD and which are not executable or writable.

	b) For all sections, load all SYMTAB and STRTAB types.

this excludes .stab, .note, and .ident. Of those, only .stab seems
to be needed.

Assuming I have the above correct, it seems there are 2 choices,
I'm not sure which one is right:

    i)	Modify biosboot to load .stab also; not sure what criteria to
    use, though, perhaps by name explicitly?

    ii) Modify the toolchain to tag .stab as SYMTAB, rather than
    PROGBITS. Possibly this could cause other problems?

I don't particularly like either of these solutions.

Any thoughts?

--jhawk