Re: PPC64 mlongcall gcc flag

[Manoel]

On Wed, 2008-11-05 at 11:25 -0600, Hollis Blanchard wrote:
> On Tue, 2008-11-04 at 18:48 -0500, Pavel Roskin wrote:
> > 
> > However, it would be nice to have a better explanation why "-mlongcall"
> > is needed.  If it's only needed for modules and has significant
> > overhead, we may want to introduce MODULE_CFLAGS, which would only be
> > used for modules.
> 
> It absolutely should only be used for modules.
> 
> It's needed because a PowerPC branch instruction can only target +/-
> 32MB. -mlongcall replaces the direct branch with an indirect one (using
> mtctr/bctrl instructions). This can target the full 32-bit address
> space.
> 
> > By the way, I tried cross-compiling for PowerPC with and without
> > "-mlongcall" with gcc 4.2.4.  With "-mlongcall", the size of all modules
> > combined is 426424 bytes.  Without "-mlongcall", the size of all modules
> > combined is 354464 bytes.  That's a significant difference for a
> > bootloader and should be avoided if possible.
> 
> To be fair, if we are that worried about footprint, why do we have a
> runtime ELF linker in a bootloader?
> 
> At any rate, the point of having dynamically loadable modules is so you
> can only load the ones you need. On that scale I think the size increase
> is less of an issue.
> 
> > Maybe there is a way to keep the modules and the core in the first 32
> > megabytes?
> 
> Actually I'm confused about something here Manoel.
> 
> Module memory is allocated by grub_malloc(), but as you can see at
> ihttp://svn.savannah.gnu.org/viewvc/trunk/grub2/kern/ieee1275/init.c?revision=1806&root=grub&view=markup
>  the GRUB heap capped at 4MB (I don't mean size, I mean the end of the heap). 
> So how are your modules appearing in memory above 32MB?
> 
I'm not sure why ( I didnt look at that part of the source code yet).
If I understand correctly the heap should only use address in the range
0x - 0x400000 (0 - 4mb).

The total modules size until the moment of failure (reallocation
overflow) is around 120 kb , then it shouldn't be a lack of memory
problem.

In the attachment we can see that the modules are relocated in a
decreasing order of address.
the firsts modules are relocated in the address range  0x2a990->0x262f0
 (in small steps). Then relocated to the address range 0x8ab0->0x4830
(small steps again).

Note that grub jumps from the address 0x262f0 to 0x8ab0., probably
because grub itself is using this address space(grub is linked at
0x10000).
until there all is ok.

but then it tries to relocate to the address 0x208f6b0 and the
"relocation overflow" problem happens.

In the P5 machine the behavior is very similar but the address 0x1c6f6b0
is used and all goes fine.


could it be a bug in the grub memory manager?
Attached is the debug information of the modules relocation in both P5
and P6.

-- 
Best Regards,

Manoel Abranches <address@hidden>
IBM Linux Technology Center Brazil

grub_loading_modules_P5
Description: Text document

grub_loading_modules_P6
Description: Text document