From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 27 Nov 2012 16:22:31 -0600
Subject: [U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address
In-Reply-To: <20121121082232.0DD3C2003CF@gemini.denx.de> (from wd@denx.de on
	Wed Nov 21 02:22:32 2012)
Message-ID: <1354054951.2317.14@tyr>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 11/21/2012 02:22:32 AM, Wolfgang Denk wrote:
> Dear Tetsuyuki Kobayashi,
> 
> In message <1353476660-18018-1-git-send-email-koba@kmckk.co.jp> you  
> wrote:
> >
> > U-Boot from NOR flash relocates itself to RAM erea. The relocation  
> address is
> > calaculated at runtime to get maxium contiguous space to load  
> kernel. So it may
> > vary after code changed. In the early debug phase it would be  
> easier to handle
> > if the relocation address does not change per build.
> 
> No, it is not.

Maybe not for you, but for some of us it definitely would make things  
easier.  I usually end up randomly peeking at some likely destinations  
until I find the expected content.

> You still need to determine where it gets relocated to,
> and iot makes no difference for debugging wehter you enter one number
> or another one.
> 
> Any debugger out there today allows you to automatemost such
> operations by scripts or functions or macros you can define to help
> you doing that.

Just because you've managed to compensate for it doesn't mean it isn't  
annoying.

How am I going to script gdb to figure out the relocation address when  
I'm just running it on the image to get symbols, not actually  
connecting to the target?

Is such a script published anywhere?

> > My idea is define fixed address as CONFIG_DEBUG_RELOC_FIX_ADDR in  
> config file
> > and relocate to the address. Then you don't need to execute  
> 'bdinfo' command to
> > get actual relocated address. It is done by the first patch.
> 
> I'm not willing to accept such change.  It appears to ad a (minimal)
> easement at first glance, but at the same time it bears potential to
> break a large number of other things, and not unlikely in areas which
> are why you need to run a debugger in the first place.
> 
> This makes no sense.
> 
> > The second patch is for u-boot_r, which is linked for fixed  
> relocation address.
> > When you want to symbolic debug after relocation, flash  
> 'u-boot.bin' and
> > load symbol from 'u-boot_r' to debugger.
> > (CF. When you want to symblic debug before relocation, load symbol  
> from 'u-boot'
> >  to debugger.)
> 
> Why would that be needed?  The standard ELF file has all debug
> information you ever may need.

If the symbols in the ELF ?file match where U-Boot is actually located,  
that avoids the need to manually apply the relocation offset every time  
you want to look at something.

> Just to save the "load symbol table" command?

Where would you get the symbol table to load that matches U-Boot  
post-relocation?

-Scott