[U-Boot-Users] code relocation and symbolic debugging

[U-Boot-Users] code relocation and symbolic debugging

[vb]

Gentlemen,

forgive me if this has been discussed before - I tried searching the
archives and could not find anything.

I don't understand the reason for the program relocation from eprom to
dram the way it is done now (with position independent data and code,
with runtime address fixes, etc.). I mean, this of course is quite an
achievement to have this working on so many platforms, but it is such
a pain, especially when trying symbolic debugging. I of course know
about the gdb add-symbol-file command, but I couldn't figure out how
to make it relocate symbols along with the text segment. As a result,
I can set breakpoints and examine automatic variables, but can't see
static/global variables using the gdb. How do others handle this
situation - any hits will be highly appreciated.

Now, I don't want to sound too much off the mark, but why is this
trick even needed?  For at least 10 years now gnu tools provide the
ability to generate bin images of the executable files and to
concatenate otherwise noncontiguous segments in one file.

Utilizing this feature would allow to benefit from all the u-boot
early startup elegant smarts (running with data in the cache, testing
the entire dram, stc)., then the first stage code would just move the
main chunk to the predefined location and pass control to it. This way
no need to worry about adjusting tabled addresses, about data not
fitting into the room allotted, about gdb not alllowing to see
variables - this approach is pretty much worry free at least on mips
and ppc architectures where I extensively deployed it before joining
the u-boot club.

Of course with such a heavy legacy like u-boot has it is difficult to
switch on a whim, but would this be even considered? And why has not
it been done like that in the first place?

Cheers,
/vb

[U-Boot-Users] code relocation and symbolic debugging

[Wolfgang Denk]

In message <f608b67d0703191805t6379c48an24ea9d9d41277d11@mail.gmail.com> you wrote:
> 
> a pain, especially when trying symbolic debugging. I of course know
> about the gdb add-symbol-file command, but I couldn't figure out how
> to make it relocate symbols along with the text segment. As a result,

Then you obviously did not read the manual. Please RTFM.

> I can set breakpoints and examine automatic variables, but can't see
> static/global variables using the gdb. How do others handle this
> situation - any hits will be highly appreciated.

We just do as described in the manual.

> Now, I don't want to sound too much off the mark, but why is this
> trick even needed?  For at least 10 years now gnu tools provide the
> ability to generate bin images of the executable files and to
> concatenate otherwise noncontiguous segments in one file.

If you want to be able to erase / progarm the flash, at  least  youyr
flash  driver must be running from non-flash memory (at leats on most
standard flash chips). If you want to be able  to  update  U-Boot  in
flash you must have all of U-Boot running in some other memory.

This requires to copy & relocate the image.

And this has nothing to do with where the code/data segments are
placed.

> Utilizing this feature would allow to benefit from all the u-boot
> early startup elegant smarts (running with data in the cache, testing
> the entire dram, stc)., then the first stage code would just move the
> main chunk to the predefined location and pass control to it. This way
> no need to worry about adjusting tabled addresses, about data not
> fitting into the room allotted, about gdb not alllowing to see
> variables - this approach is pretty much worry free at least on mips
> and ppc architectures where I extensively deployed it before joining
> the u-boot club.

Feel free to submit patches - if they actually work we will be  happy
to consider them.

I'm just afraid that you miss a few points...

> Of course with such a heavy legacy like u-boot has it is difficult to
> switch on a whim, but would this be even considered? And why has not
> it been done like that in the first place?

Because nobody was clever enough to implement it? Or maybe because it
does not work? Dunno...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Text processing has made it possible to right-justify any idea, even
one which cannot be justified on any other grounds."
                                                 -- J. Finnegan, USC.

[U-Boot-Users] code relocation and symbolic debugging

[vb]

Wolfgang, thank you again for a prompt reply, please see below:

On 3/19/07, Wolfgang Denk <wd@denx.de> wrote:

>
> If you want to be able to erase / progarm the flash, at  least  youyr
> flash  driver must be running from non-flash memory (at leats on most
> standard flash chips). If you want to be able  to  update  U-Boot  in
> flash you must have all of U-Boot running in some other memory.
>
> This requires to copy & relocate the image.
>
> And this has nothing to do with where the code/data segments are
> placed.
>

of course, no doubt relocation is required both for reasons you
mention, as well as to improve performance, etc. I was asking about
using position independent code/data, recalculating addresses, etc.

> > Utilizing this feature would allow to benefit from all the u-boot
> > early startup elegant smarts (running with data in the cache, testing
> > the entire dram, stc)., then the first stage code would just move the
> > main chunk to the predefined location and pass control to it. This way
> > no need to worry about adjusting tabled addresses, about data not
> > fitting into the room allotted, about gdb not alllowing to see
> > variables - this approach is pretty much worry free at least on mips
> > and ppc architectures where I extensively deployed it before joining
> > the u-boot club.
>
> Feel free to submit patches - if they actually work we will be  happy
> to consider them.
>
> I'm just afraid that you miss a few points...
>
> > Of course with such a heavy legacy like u-boot has it is difficult to
> > switch on a whim, but would this be even considered? And why has not
> > it been done like that in the first place?
>

well, I am sure I can make it work for PPC and I can test it because I
am working on a PPC board right now, would you allow introducing this
different approach just on PPC to start with?

cheers,
/vb

> Because nobody was clever enough to implement it? Or maybe because it
> does not work? Dunno...
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "Text processing has made it possible to right-justify any idea, even
> one which cannot be justified on any other grounds."
>                                                  -- J. Finnegan, USC.
>

[U-Boot-Users] code relocation and symbolic debugging

[vb]

On 3/19/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <f608b67d0703191805t6379c48an24ea9d9d41277d11@mail.gmail.com> you wrote:
> >
> > a pain, especially when trying symbolic debugging. I of course know
> > about the gdb add-symbol-file command, but I couldn't figure out how
> > to make it relocate symbols along with the text segment. As a result,
>
> Then you obviously did not read the manual. Please RTFM.
>
> > I can set breakpoints and examine automatic variables, but can't see
> > static/global variables using the gdb. How do others handle this
> > situation - any hits will be highly appreciated.
>
> We just do as described in the manual.
>
Wolfgang, I just checked again, and I know what happened: this chapter

http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.

never mentions tricks listed in this chapter:

http://www.denx.de/wiki/view/DULG/GDBScripts,

and I did not look any further than section 10.1.2 when I read the
manual first time. I think it would benefit section 10.1.2 if it
mentioned that more stuff is available further down the manual.

Sorry for missing it first time around,
cheers,
/vb

[U-Boot-Users] code relocation and symbolic debugging

[Daniel Hobi]

On 20.03.2007 03:19, vb wrote:
> http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
> 
> never mentions tricks listed in this chapter:
> 
> http://www.denx.de/wiki/view/DULG/GDBScripts,
> 
> and I did not look any further than section 10.1.2 when I read the
> manual first time. I think it would benefit section 10.1.2 if it
> mentioned that more stuff is available further down the manual.

The articles you mention are part of a wiki. Feel free to improve the 
articles yourself.

Have a look at http://www.denx.de/wiki/TWiki/WelcomeGuest.

Best Regards,
Daniel

[U-Boot-Users] code relocation and symbolic debugging

[Wolfgang Denk]

In message <f608b67d0703191852x69f47cfbk5f9432b8e690f6c3@mail.gmail.com> you wrote:
> 
> well, I am sure I can make it work for PPC and I can test it because I
> am working on a PPC board right now, would you allow introducing this
> different approach just on PPC to start with?

Anything that works (identical on as many as possible platforms)  and
leads to simpler and/or cleaner code is welcome.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One friend in a lifetime is much; two  are  many;  three  are  hardly
possible. Friendship needs a certain parallelism of life, a community
of thought, a rivalry of aim.                     - Henry Brook Adams