Using newlib (was: [Efi332] Building newlib/libgloss for MPC555)

[Gunter Magin]

Hi David

On Mon, Aug 08, 2005 at 07:54:45PM -0700, David Eicher wrote:
> Well, I tried executing my freshly built target code that has newlib and
> libgloss in it. The code ran perfect until it hit the first call into newlib
> (libc), the call was to printf( ). 

What exactly happened? Hangup? Crash with Reboot? It could very well
be that the linking system is perfectly ok, but there is a bug in the
serial driver, e.g. you are hanging in a busy loop checking for a change
in a status bit which never happens. For example because the volatile
keyword has been missing on the status register...

So did printf reach your outbyte function? You can use a "LED debugger"
to make sure this happens (that is, set a GPIO when you enter outbyte(),
and put it off again on leaving). If the LED doesn't go on, and you are
unsure if it's the LED control calls or not reaching outbyte(), use the
LED debugger in main. Have some measurement equipment handy (e.g. scope,
logic probe, even a $40000 logic analyzer will do it... :-) ) to monitor
the LED output, because you can expect pretty short pulses for such a
fast processor... 

> Below is a output from linking my target
> with -v option on linker. Not sure if that will tell anyone anything useful,
> it doesn't help me with my limited experience.

We need the contents of the map file...

> I'm a bit confused about what tells make to use the rs6000 version of
> libgloss? Not sure how that is being picked up. When I go through my
> main.map file I do indeed find encouraging stuff there, my modified
> mbx-outbyte.o and mbx-inbyte.o are there, so I can't be too far off. 

Ok, that's the relevant info. 

> Gunter, I'm trying to understand what to change if I go back and configure
> again. I haven't modified any makefiles for newlib or libgloss. 

> /usr/local/zfi555FBMonitor/bin/pcmaster.o
> /usr/local/zfi555FBMonitor/bin/main.o -o main.elf -mcpu=555 -Wl -Tdebug
> .dld -Wl,-Map=main.map -nostartfiles -lc -lm -lmbx -v
                                               ^^^^^
What's this? Have you cheated and modified the stock mbx libgloss to support
your home brewed HW? What about the yklib.a? Scrapped? 

> I tried changing the linker switch from -melf32ppc to -mcpu=555, linking
> went fine, but no change in printf behavior.

So did it pick another outbyte.o? Check the map file if there are
differences. Emphasize on the path from which libmbx.a is picked.

> I don't have a source level debugger running yet. I suppose it is time. I
> can't troubleshoot printf using the OCDComander from Macraigor, it is
> assembly code level, and I don't have list files for the libraries (like
> mbx-outbyte.lis). And, I don't know how to create them.

powerpc-elf-objdump -d xxx.o >xxx.dis

or 

powerpc-elf-objdump -D xxx.o >xxx.dis

might deliver a substitute. (check the manual for xxx-yyy-objdump) At
least you get a connection between C-function and assembler. Use the
map file to find out which function is linked to which address, or,
vice-versa, which function is sitting at a particular target memory
address. But debugging C code on assembler level is VERY tedious and
probably a waste of time, if you are doing it for the first time.

> I suppose I need to start the project of getting gdb/insight to work,
> probably will need it later anyway.

I'd rather use the "sharp-eyed-protein-debugger", (which by the way
is free to use, and already available, though might have some not yet
implemented debugging features) by carefully sifting through your device
driver. Make a kind of a simulated dry run-thru, and check for conditions,
branches... Some people call this a code walk-thru.

If you sidetrack now to set up the debugger, you might forget half
the wisdom how you came to that particular dev env state, before it
is stable...

gm