printf() problem with ported NewLib

IanSeyler · **Posted:** Thu Apr 25, 2013 2:49 pm

I'm wondering if anyone else has seen this behavior.

Example:

Code:

printf("NewLib Test Application\n=======================\n");
printf("%s %d\n", "Output:", 1234);

Result:

Code:

NewLib Test Application
Output: 1234

The NewLib write() function was only called to print 24 characters on the first call to printf().

Kazinsal · **Joined:** Wed Jul 13, 2011 7:38 pm **Posts:** 558

I would wager it's because of the newline and not an arbitrary 24-character limit. Try removing the newline?

IanSeyler · **Posted:** Fri Apr 26, 2013 8:56 am

Code:

Code:

printf("NewLib Test Application=======================\n");
printf("%s %d\n", "Output:", 1234);

Results:

Code:

NewLib Test Application=======================
Output: 1234

Looks like it stops printing after the first newline. That first call to printf() should result with one call to write(), correct?

Kazinsal · **Joined:** Wed Jul 13, 2011 7:38 pm **Posts:** 558

My crystal ball tells me you haven't implemented isatty() and/or fstat(), so newlib is confused as to what buffering to use.

Antti · **Posted:** Fri Apr 26, 2013 10:01 am

Does your write() correctly handle the newline?

bluemoon · **Posted:** Fri Apr 26, 2013 12:13 pm

ReturnInfinity wrote:

Looks like it stops printing after the first newline. That first call to printf() should result with one call to write(), correct?

In my implementation, newlib make 2 calls to write with if there is line feed in middle of string:

Code:

printf ("  PID[%d]: Hello again! counter=%d, foo=%d\n   line2\n", pid, i, g_foo.foo++);


Result:
SYSCALL : fstat(1, 7FBFF7D0)
SYSCALL : sbrk(00000430)
SYSCALL : sbrk(00000BD0)
SYSCALL : write(1, 01000010, 20)
FOO::FOO(0x10d008);
SYSCALL : write(1, 01000010, 21)
FOO::FOO(0x1000420);
SYSCALL : getpid() -> FFFFFFFF:801210D0: 1
SYSCALL : write(1, 01000010, 42)
  PID[1]: Hello again! counter=0, foo=123
SYSCALL : write(1, 01000010, 9)
   line2
SYSCALL : usleep(000F4240)

My fstat:

Code:

long kservice_fstat(int fd, struct stat* st) {
    kprintf ( "SYSCALL : fstat(%d, %p)\n", fd, st);
    if ( st == NULL ) return -1;
    st->st_mode = S_IFCHR; // | S_IWUSR;
                           //    st->st_blksize = 1;
    return 0;
}                   

IanSeyler · **Posted:** Fri Apr 26, 2013 12:40 pm

Blacklight, isatty() looks fine.. it was just returning 1 be default. I changed it to return 1 for STDOUT and STDERR. fstat was just set to minimal implementation of returning 0. I'll take a further look at fstat().

Antti, write() handles the newlines correctly. write(1, "test1\ntest2\n", 12) works as expected.

IanSeyler · **Posted:** Fri Apr 26, 2013 1:35 pm

I think my issue is with sbrk(). A really simple program crashes whereas a more complicated one doesn't.

I get a page-fault with this:

Code:

#include <stdio.h>

int main()
{
    printf("Hello1\nHello2\nHello3\n");
    return 0;
}

I'll do some digging and report back.

IanSeyler · **Posted:** Mon Apr 29, 2013 2:46 pm

My sbrk() is borked (I think)! I'm also thinking it could be due to me not zeroing BSS.

Should I be implementing a crt0.c file to run before calling main?

Should NewLib work correctly with flat binaries?

My linker script:

Code:

OUTPUT_FORMAT("binary")
OUTPUT_ARCH("i386:x86-64")
ENTRY(main)
SECTIONS
{
        . = 0x0000000000200000;
        .text : { *(.text) }
        .data : { *(.data .rodata) QUAD(ADDR(.bss)+SIZEOF(.bss)) }
        .bss : { *(.bss) }
        end = .; _end = .; __end = .;
}

How I compile:

Code:

gcc -I ../../newlib-2.0.0/newlib/libc/include/ -c helloc.c -o helloc.o
ld -T app.ld -o helloc.app helloc.o libc.a

More debugging to do!

Owen · **Posted:** Mon Apr 29, 2013 4:25 pm

ReturnInfinity wrote:

I'm also thinking it could be due to me not zeroing BSS.

That is part of the contract for BSS...

bluemoon · **Posted:** Mon Apr 29, 2013 11:34 pm

Owen wrote:

ReturnInfinity wrote:

I'm also thinking it could be due to me not zeroing BSS.

That is part of the contract for BSS...

LOL, I saw at least 5 people on this forum, including myself, made this mistake :mrgreen:

I know, when you drag newlib into your OS you just can't wait to make some test application, and missed this (and other) critical parts.

sortie · **Joined:** Wed Mar 21, 2012 3:01 pm **Posts:** 930

If you don't already, you ought to be using a real cross-compiler to build your kernel and user-space. Please do that.

dozniak · **Posted:** Tue Apr 30, 2013 2:40 am

bluemoon wrote:

Owen wrote:

ReturnInfinity wrote:

I'm also thinking it could be due to me not zeroing BSS.

That is part of the contract for BSS...

LOL, I saw at least 5 people on this forum, including myself, made this mistake :mrgreen:

I know, when you drag newlib into your OS you just can't wait to make some test application, and missed this (and other) critical parts.

If you're using multiboot bootloader, it clears out the bss for you. In any other case - it's up to you.

bluemoon · **Posted:** Tue Apr 30, 2013 3:05 am

dozniak wrote:

If you're using multiboot bootloader, it clears out the bss for you. In any other case - it's up to you.

Quote:

NewLib Test Application=======================

I presume we are dealing with loading application, not about loading the kernel from boot loader.

dozniak · **Posted:** Tue Apr 30, 2013 5:24 am

bluemoon wrote:

dozniak wrote:

If you're using multiboot bootloader, it clears out the bss for you. In any other case - it's up to you.

Quote:

NewLib Test Application=======================

I presume we are dealing with loading application, not about loading the kernel from boot loader.

Oh, indeed. In this case the crt should deal with that.

OSDev.org

printf() problem with ported NewLib

Who is online