[Crash-utility] x86 remap allocator in kernel 3.0

[Dave Anderson]

----- Original Message -----
> Dne St 11. ledna 2012 15:37:50 Dave Anderson napsal(a):
> > ----- Original Message -----
> > 
> > > Dne St 11. ledna 2012 00:37:50 Petr Tesarik napsal(a):
> > > > [...]
> > > > I can see now that this is unnecessarily complicated, because the
> > > > node_remap_* variables are static arrays of MAX_NUMNODES elements, so I
> > > > can get their size from the debuginfo at POST_GDB init and initialize a
> > > > machine-specific data type with it. I'll post another patch tomorrow.
> > > 
> > > And here we go. Tested on my system and seems to work just fine.
> > > 
> > > Petr Tesarik
> > > SUSE Linux
> > 
> > Hi Petr,
> > 
> > This looks pretty good to me.  However, just to clarify the
> > chicken-and-egg situation here...
> > 
> > When remap_init() does these 3 readmem() calls, they will pass
> > through x86_kvtop_remap() -- which I guess would fail because
> > the arrays would still be at least partially uninitialized?:
> 
> Hi Dave,
> 
> first of all, it's not a real issue, because kernel static data is always
> below the remapped addresses, but I agree, it's ugly and making non-obvious
> assumptions about memory layout. To make things clean, I can simply set
> machdep->machspec->max_numnodes as the last thing, so the loop in
> x86_kvtop_remap() cannot be executed until everything is initialized.
>
... [ cut ] ...
> 
> Patch attached.
> 
> Petr Tesarik
> SUSE Linux

That works -- and with a cleanup for these minor "make warn" issues:

cc -c -g -DX86 -m32 -D_FILE_OFFSET_BITS=64 -DGDB_7_3_1  x86.c -DMCLX -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector 
x86.c: In function ‘x86_dump_machdep_table’:
x86.c:3578: warning: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘int’
x86.c:3435: warning: unused variable ‘j’

...it's queued for crash-6.0.3.

Thanks Petr,
  Dave