Re: [microblaze-uclinux] Kernel crash debug: No code generated for'get_romfs_base()' function?

[Greg Ungerer <gerg@xxxxxxxxxxxx>]

Hi John, David,

John Williams wrote:
> David Banas wrote:
>> I was just single-stepping through the early boot sequence, under 
>> control of
>> gdb, and noticed that I couldn't stop on lines 153 or 154 of 'machine.c'.
>> Furthermore, those 2 lines didn't appear to be getting executed properly.
>> For instance, the 'get_romfs_base' function simply returns the starting
>> address of the '.BSS' segment. However, when I arrived at line 156, 
>> below, I
>> found 'src' to be equal to '0'! 'len' was also equal to '0'. And, so, no
>> copying of the '.romfs' section was being performed and, therefore, 
>> some of
>> my '.romfs' data was getting wiped out when the '.BSS' section was zeroed
>> out in the subsequent lines of code. (I can't imagine that having any 
>> of my
>> '.romfs' section erased is healthy.)
> 
> 
> BSS, being the stack segment, is not actually present in the raw kernel 

Normally the segment referred to as BSS only contains the un-initialized
data. Certainly true for the kernel, the stack is just setup somewhere
else in memory at runtime.

Regards
Greg




> image.  It's really just the promise of a memory section...  When 
> appending the romfs image to the kernel image to create image.bin, we 
> place the romfs immediately at the BSS address.  Then, in the early 
> setup we copy the romfs away from BSS to where it belongs, then zero the 
> BSS to get the initial kernel stack ready.
> 
> That said, it does seem a bit strange that your src and length values 
> for the romfs copy would be zero.  Can you please post your kernel 
> .config file (linux-2.4.x/.config)?  Preferably filtered to remove all 
> comment lines, otherwise it's a bit long.
> 
> 
>> I was very curious as to why these 2 lines were getting skipped. So, I 
>> used
>> gdb's 'info line' command to take a peek at them. I found (as you can 
>> see,
>> below) that there was no code being generated for them!!! 
>> (Incidentally, all
>> this analysis was performed immediately after freshly downloading both 
>> the
>> bit stream and the RAM image and before any instructions were allowed to
>> execute, just to ensure that I was not seeing the product of program
>> corruption due to errant code.)
> 
> 
> As Claudio says, compiler optimisations can make the code seem somewhat 
> strange in the debugging context, loops being re-ordered and so on. 
> However, simply reducing the -O level on the kernel is not easy - in 
> fact much of the kernel will not compile at -O0 due to vaious 
> optimisations wired into the coding style.  This is a generic Linux 
> thing, not just for Microblaze.  I think you'll find that in 
> arch/microblaze/Makefile you can probably specify -O1, at least that 
> will be a little less aggressive than -O2.
> 
> Regards,
> 
> John
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : 
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/