Page 1 of 1

Odd problem with printf

Posted: Sun Jun 09, 2019 1:24 am
by jacotton
I have found a problem that I can't work around (sorta).
I pushed code to my github inttools-z80. The problem is seen when trying to build and run

This is a test program used to wring out the ctc interrupt code. But I am having a problem with printf not working as expected.

Please look at ctcdriver.c, there is a call to loader (loader.c) that takes in 2 strings. I am attempting to print the stings in loader
but no joy. If however I print the strings in the calling function, everything starts to work. This has been vexing me for about
a week. I keep thinking that I really do know how to use printf, but I don't seem to be good at it....

Anyway, maybe someone can take a peek at the code and inform me what I am doing wrong.

I have looked at the C inline with the asm listings, and I don't spot any difference in loader.c, in ctcdriver.c I find more push
and pop of the hl register, but it looks like the stack is balanced.
here is the output I get with code at needed.

Running on ZSDOS
Open s
Loading: s

Here is what I get when I add the printf in the caller function.

Running on ZSDOS
CTCINT.HEX Loadable CTC interupt handler
Loading: Loadable CTC interupt handler

Posted: Sun Jun 09, 2019 12:00 pm
by stefano
interrupts can be nasty beasts.
I'm not sure I'm able to help but probably someone in the list is, please add links to your code in github, etc.

Posted: Mon Jun 10, 2019 3:11 am
by jacotton
Hi Stefano: This issue is present without my program interrupts enabled. Of course the system is rigged for mode 2, but I can't see how that effects a printf in this way.
Well, just ran a test with all the interrupt code removed. No change. It's got to be a stack/printf issue but I just don't see it.

Is there a pragma that will force printf to reveal its pointers and so on ? kind of a debug for printf ?

Posted: Mon Jun 10, 2019 7:09 am
by dom
Sorry, it's taken me a while to properly read your post.

We do "smart" format handling for the printf and scanf families. That is we only include the formatters that we detect. This information is conveyed to the linker via the zcc_opt.def which is built up during a single invocation of zcc and is reset at the start of each zcc invocation.

Looking at your makefile you've got multiple invocations of zcc so whatever format specifiers (if any) are defined in the last file will be the ones that are linked in - and from your output it looks like the '%s' formatter isn't in there - hence you just get an 's' being printed.

Probably the easiest way to solve is this (in your setup) is to create a new .c file that is compiled last of all with the following line:

Code: Select all

#pragma printf "%s %d %02x"
Adjust the formatters to match those used by your program and hopefully it will work.

There is also a -preserve flag for zcc which will not delete the zcc_opt.def file: you could put that on all but the first zcc invocations.