Re: How to get printf() output?

[Toralf Lund <toralf at procaptura dot com>]

Kai Ruottu wrote:

> Toralf Lund <toralf@procaptura.com> wrote:
>
>  
>
> > Ken Rose wrote:
> >
> >    
> >
> > > Toralf Lund wrote:
> > >
> > >      
> > >
> > > > Can someone repeat for me what I should do to get printf() to work 
> > > > when linking with newlib, but not libgloss? I was under the 
> > > > impression that write() would be called eventually, but it looks like 
> > > > it isn't. I've tried step-tracing the printf execution via the ROM 
> > > > monitor to find out what is going on, but it's a bit hard to follow...
> > > >        
>
> One can track the 'execution' even without any monitor, hardware etc., by
> simply making a disassembly output from the produced executable and then
> searching 'write', which one knows being the 'low-level I/O' routine needed.
>  
I know how write() works, I just don't think it's called at all. And 
printf() is quite hard to trace in disassembler output as the routine 
doesn't go directly to write() or or anything; there are about a zillion 
intermediate steps.

> The 'write()' in libgloss seems to use the 'outbyte()' which writes one
> char at a time to the serial port (via the monitor on the board):
>  
[ ... ]

I have my own write() that does the same thing.

> The usual way to make a disassembly listing is to use the :
>
>    m68k-elf-objdump -dr <executable-name>
>  
Yep, I've tried that already.

> command (and redirecting it to 'less' etc.)...
>
> Instead of doing this kind of 'reverse engineering', one can also
> look at the sources (or the provided documentation) for newlib,
> here 'libgloss/write.c' :
>  
[ ... ]

> If you didn't use the previous 'monkey-like' approach in your low-level
> I/O-implementation, ie. not using the provided 'write()' etc. and then
> writing your own 'outbyte()', 'inbyte()' etc., basically you are on your
> own. Otherwise you could simply show your 'outbyte()' and ask what is
> wrong with it... 
>  
It works. I'm 100% sure about that. write() could be incorrect, as I 
haven't tested its functionality thoroughly - I've been focusing on 
checking whether it is called or not, and I think it isn't ;-(

>  
>
> > > If isatty() claims that stdout isn't a tty, then printf will buffer 
> > > the output.  The quick way to test this theory is to do fflush(0) to 
> > > push all the putput out.
> > >      
> > isatty() should be correct, and I've also tried fflush(0), but still no 
> > output...
> >    
>
> I'm not that much familiar with the m68k-support, so I would use the
> 'monkey-like' approach if needing to implement the I/O-routines for
> something new...
>  
Well, like I said: The problem is not implementing the I/O routines as 
such, it's figuring out if and when they are called.

> So my advice is that you would check your I/O-implementation once
> again, the bug most probably is there...
>  
Possibly, but I'd really like to know how everything is supposed to work 
on a higher level than that.

- Toralf



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com