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

[Gunter Magin]

Hi,

> It's hard to tell what happened when I run the code because I don't trust
> this debugger. I did set a software breakpoint at mbx-outbyte, it never got
> there. The debugger says the machine is still running (not in BDM debug
> mode), but nothing is happening. So I click on "halt" and check the PC reg
> and find I'm at 0x1000 with an illegal opcode. The exception vectors go
> 0x100 through 0xE00, I don't find one for 0x1000 so I'm not sure why it goes
> there.

Table 3-21 on the MPC555UM says 0x1000 is "Implementation dependent SW
emulation", that is, an illegal opcode. Chances are the linker has
picked the wrong library. Double check the map file.

> Yes, I modified the mbx routines. Bad idea? 

For long term, yes, as it leads people (including yourself - been there,
done that) on false tracks and assumptions. For a short-term hack, it
is ok. Just take a chissel and carve on the rim of your CRT: "Don't
forget to fix the mbx hack, once it's running...." :)

> It sounds like you're saying I should make a complete new one (called
> 555pcc, for example), correct? 

Yes. But not necessarily now. That's the clean way.

> I figured that would be more complicated, I'd
> have to modify makefiles to do that. If it's necessary though, I'm willing.

Not the makefiles, but the the makefile.in. And it is only one or two
files. No big deal.

> Let me make sure I understand, you recommend a code walk-through of printf(
> )? Okay, made a quick walk through.., printf calls vfprintf, it appears.
> Vfprintf calls print, and print calls outbyte.

No, not printf. newlib is known to be reasonable bug free, and the
remaining bugs will not bother you at this state. Start at the place
where the processor comes out of the libc black box, that is the
open() and write() function. write() calls outbyte(). Emphasize on all
conditioinal branches, changes in variables, leftover states of
variables, side effects, and don't let you bother what the programmer
intended, but presume to be the stupid processor doing exactly what's
written down. Build hypotheses about what might cause your observations,
and if you don't have enough information, make additional tests. Once
the LED debugger is working, I would experiment a little more with the
LED debugger to get a better feeling what's happening.

But it looks like you don't reach write() at all. This would be my very
first test.

> I'll try the objdump to get listings and put some debug code in there and
> see what I can learn tonight.

You can also disassemble the whole app elf file and find out if there
are some strange opcodes in printf() code. But what looks strange? Only
the processor knows...

You can also give the debugger another try and analyze the stack once
you reach the illegal opcode exception. I think setting a breakpoint
at 0x1000 and analyzing the processor registers might give valuable
information. That's at least worth a try.  Then use the map file to
locate the offending opcode, and the function.

gm