Re: [PATCH] Do not inline putprops function

[Michael Ellerman <michael@ellerman.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote:
> On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote:
> > On Wed, Jun 17, 2009 at 10:40:07AM -0400, Neil Horman wrote:
> >  
> > > > send objdump of fs2dt.o with and without this assignment.
> > > > 
> > > That would be a fine thing to do, and I'd be happy to compare them.  My though
> > > regarding the comparison of the device tree on a good and bad run was meant to
> > > expidite what change in the assembly we'd be looking for.  If its the kdump
> > > kernel boot thats hanging, Its likely hanging on something in the device tree,
> > > as thats whats being manipulated by this code.  So I figure that understanding
> > > whats changed there will point us toward what change in the assembly might be
> > > responsible for the hang.  The assmebly's going to be signficantly different
> > > (lots of optimization might be lost from no longer inlining a function), so
> > > anything that helps us narrow down whats changed will be good
> > 
> > I am attaching the objdumps of fs2dt with and without dt_len.
> > 
> Well it definately looks like removing that variable had some code changes.
> It'll take some time to match it up to source, but Most interesting I think is
> the variance in putprops around address f34.  Looks like its doing some string
> maniuplation in a reversed order, using a huge offset.  Might be worthwhile to
> check to see if theres any string overruns in this code.

Yeah I still suspect it's just a bug in the code that's being exposed
now.

Mohan, can you try running it under valgrind?

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]