How to relay a varargs function? [SOLVED]

Hi

I need to make a stub for a varargsfunction, but how on earth do I relay the arguments??!

In a macro you can receive the args with '...' and send them on using __VA_ARGS__ but that doesn't work in a funciton.

Help.

@Deniil

http://docs.embarcadero.com/products/ ... /devwin32/va_arg_xml.html

@LiveForIt

Thanks, but not exactly what I needed. I need to relay varargs, not use them.

See this example:

@Deniil

You need two functions in this case then: one for variable arguments and one with just one fixed argument. In every C runtime library you have something like fprintf() and vfprintf(). fprintf() is the vararg function while vfprintf() takes a single argument only (apart from the stream variable).
Internally things are done like this:

@tboeckel

Ok, so that is the actual solution to the problem. I suspected that is what I have to do, and that's great. Thanks.

I got the impression that the "hidden implementation" also had a set of varargs, but maybe it actually doesn't. Varargs *only* exist in the API and are translated by the stub/glue code.

It's a bit sad that C make varargs even needed... In E one would use an inline list or struct, or list of struct which makes varargs unneeded and also allows typechecking.

@Deniil

An extra subtley on AmigaOS4 if you are writing an varags entry point to a .library or one that uses tags, passes BOOPSI messages etc etc you must use the linearvargs macros see the migration guide in the SDK. I'f type it out in detail but I always get them wrong if I don't read the doc first so better if you read teh doc directly

As to you point about it being sad to need them, languages differ bt most have some variation on them, as there is a need to pass arandom list of untyped data (see printf for the most variable of varargs). In the case of printf et al the modern compiler will do some compile time type warnings, if the args don;t match the template.

@Deniil

I've seen this in some open-source code and it seems to work:

#define lsprintf(buf,fmt,...) \
({ \
ULONG vargs[] = { __VA_ARGS__ }; \
RawDoFmt((STRPTR)fmt, (APTR)&vargs, NULL, (APTR)buf); \
})

See the CPP docs about __VA_ARGS__ .

@broadblues

Thanks. I'm using the SDI stuff so it should take care of this.

@xenic

Yes, but this is a macro, and about _using_ varargs. Anyway, I let SDI take care of the syntax and put the wrapper in the interface stubs.


Now I have a wierd problem that DebugPrintF() won't output anything to the debug buffer log. I get a crash in a code path I know have several DebugPrintF but no output. Worked yesterday....

@Deniil
Quote:
That could be due to a bug I reported in Oct 2013. Refer to the "Debug output bug" topic in the "General AmigaOS" forum at the "Hyperion Entertainment Message Boards". When you turn your system on or perform a cold reboot (reset) the debug output goes to the debug buffer. After a warm reboot (Ctrl-A-A) the debug output is rerouted to the serial output.

@xenic

What system is that on? Both my systems work fine (SAM X1k )WRT debug going to serial or memeosry as required.

@Deniil

If you have a 68k program containing something like this:



to work on OS4 you have to change it like this:

@broadblues
It happens on my SAM Flex and X1000 with no changes to CFE UBOOT or Kickstart. When OS4 Final was released, the default for debug output was changed to the internal buffer. It remained that way until Oct 2013. If you check the report I referenced you'll see that the problem was confirmed by nbache.

Unless you've changed your CFE or UBOOT settings, it's easy to reproduce. Compile a small program that writes some text with DebugPrintF(). Write some debug text after cold booting and enter "dumpdebugbuffer clear" in a shell. You'll see your text in the debug dump. Warm reboot, perform the same procedure and you won't see your debug text in the debug buffer dump.

@xenic

That's it! It was after a warm reboot it stopped working.

How do I fix it? Is there an OS4 command to change the output while running? Is there a CFE setting (X1000) I can set to lock it to the buffer?

@Thomas

Thanks. I'm not porting 68k code though, and I'm using the SDI macros.

@Deniil
Quote:
Open a shell and enter "kdebug console memory" before running the program you want to test. It might be possible to add "kdebug console memory >NIL:" at the bottom of your user startup but I haven't tried that. If you add it to your user-startup, remember that you put it there (so you can remove it) in case you want to connect a serial cable and use serial output for debugging.

@xenic

Hmm I'm pretty much always using serial so perhaps I missed that change.

Setting the KDebug command in the startup-sequnec is the best solution if you must use the debug buffer. It's what it's for after all

*But* I'd strongly recomend using serial instead. It's far more flexible and is real time, ie you see the debug in the terminal or sashimi more or less as it happens.

Dumpdebugbuffer is only useful after the event and the data doesn't survive a hard reboot.

And you can redirect sashimi output to a file if need be.

@broadblues

How do I use sashimi on OS4/X1000?

@Deniil

get it from os4depot

http://os4depot.net/index.php?functio ... lopment/debug/sashimi.lha

Add the serial option to the os4 boot command line

NVSetVar os4_commandline "SERIAL"

on sam or via CFE on an x1k

Then simply type sdk:tools/sashimi/sashimi in a shell

@Deniil
Quote:
Here is the commandline I use to start sashimi:

Run >NIL: *>NIL: Sashimi BUFK=64 NOPROMPT ASKEXIT ASKSAVE CONSOLE WINDOW="CON:76/28/800/180/Sashimi/CLOSE/ALT76/28/800/684 [Ctrl]+E=Empty [Ctrl]+F=File [Ctrl]+D=Reset/AUTO/CLOSE/WAIT/INACTIVE/NOICONIFY"

Due to the length of the above command, I put that command in a file and call it as a script. I've never had to change anything to use Sashimi on my system so you might want to test to see if it works for you before changing your CFE or UBoot settings.

@broadblues
I don't think the average user want's to make/purchase a null-modem cable, configure a terminal program and keep a computer tied up as a debug terminal for their Amiga. Search the "Hyperion Entertainment Message Boards" for the word "dumpdebugbuffer" and see how many times people have suggested using that command. Unfortunately, most people aren't aware that the debug output isn't going to the debug buffer after a warm reboot and the dumpdebugbuffer command is useless unless debug output is redirected to the memory buffer with a command.

The change in the debug buffer occurred after some Kickstart files were changed in Oct. 2013. Deniil's experience with dumpdebugbuffer failure is good example of the confusion that's been caused by the change.