Brent W. Baccala, on Thu 11 Aug 2016 15:29:27 -1000, wrote:
> On Wed, Aug 10, 2016 at 4:33 AM, Richard Braun <[1]rbr...@sceen.net> wrote:
>
> On Wed, Aug 10, 2016 at 04:26:35PM +0200, Richard Braun wrote:
> > the boot loader (see MULTIBOOT_FLAGS in boothdr.S), and at
> > some point, late during the boot process, module data are freed
> > using (see free_bootstrap_pages in bootstrap.c). This might
>
> Using vm_page_manage().
>
> The symbol table is far enough away from the module data that I don't think
> it's getting freed at that point.
Ok, but:
> But it does seem to be freed. Please check my calculations.
>
> Here's the location of the symbol table in virtual memory.
>
> (gdb) print self->start
> $15 = (Elf32_Sym *) 0x804fb5ec
That's very far. i386/intel/pmap.c's pmap_bootstrap uses the etext
symbol so as to know what to make read-only, notably. We'd probably want
to make the symbol table read-only too.
Looking at the output of the biosmem code on my box:
biosmem: physical memory map:
biosmem: 000000000000000000:00000000000009fc00, available
biosmem: 00000000000009fc00:0000000000000a0000, reserved
biosmem: 0000000000000f0000:000000000000100000, reserved
biosmem: 000000000000100000:00000000007ffe0000, available
biosmem: 00000000007ffe0000:000000000080000000, reserved
biosmem: 0000000000feffc000:0000000000ff000000, reserved
biosmem: 0000000000fffc0000:000000000100000000, reserved
biosmem: heap: 114f000-7a000000
and objdump shows:
LOAD off 0x00001000 vaddr 0x81000000 paddr 0x01000000 align 2**12
filesz 0x00114700 memsz 0x00114700 flags r-x
LOAD off 0x00116000 vaddr 0x81115000 paddr 0x01115000 align 2**12
filesz 0x0000d151 memsz 0x00039384 flags rw-
It seems biosmem's heap doesn't even exclude the kernel data?!
Samuel
