How to get printf() output?

[Toralf Lund]

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