public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bruce Korb <bruce.korb@gmail.com>
To: libffi-discuss@sourceware.org
Subject: *printf functions
Date: Fri, 24 Apr 2015 21:54:00 -0000	[thread overview]
Message-ID: <553ABBA4.40505@gmail.com> (raw)

Hi,

My number 1 need is for calling printf functions based upon derived information.
Since there is no widespread argument vector implementations of *printf
(the abortive "snprintfv" library excepted due to the "widespread" requirement),
I need to construct calls to the snprintf function.  I know about the vararg
caveats, but there is also the notation that "it often works anyway", so I
was hoping that it would for snprintf under Linux on an x86-64:

> $ /lib64/libc.so.6
> GNU C Library (GNU libc) stable release version 2.18 (git ), by Roland McGrath et al.
> Copyright (C) 2013 Free Software Foundation, Inc.

> $ gcc --version|head -n2
> gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]
> Copyright (C) 2013 Free Software Foundation, Inc.

So, I constructed this call

> Breakpoint 1, print_one_event (evd=0x7ffff5ecc088) at evt/src/event-print.c:181
> 181                             ffi_call(&cif, snprintf_fn, &snprintf_res, values);
> (gdb) p cif
> $1 = {abi = FFI_UNIX64, nargs = 5, arg_types = 0x663c1f0,
>   rtype = 0x40e490 <ffi_type_uint32>, bytes = 0, flags = 9}
> (gdb) p cif.arg_types[0]
> $2 = (ffi_type *) 0x40e510 <ffi_type_pointer>
> (gdb) p cif.arg_types[1]
> $3 = (ffi_type *) 0x40e4d0 <ffi_type_uint64>
> (gdb) p cif.arg_types[2]
> $4 = (ffi_type *) 0x40e510 <ffi_type_pointer>
> (gdb) p cif.arg_types[3]
> $5 = (ffi_type *) 0x40e490 <ffi_type_uint32>
> (gdb) p cif.arg_types[4]
> $6 = (ffi_type *) 0x40e490 <ffi_type_uint32>
[...]
> (gdb) p (char *)values[0]
> $10 = 0x7fffffffc6b4 ""
> (gdb) p *(int*)values[1]
> $11 = 4044
> (gdb) p (char *)values[2]
> $12 = 0x40e360 "Allocated sblock_id=%d for band_id=%d\n"
> (gdb) p *(int*)values[3]
> $13 = 1
> (gdb) p *(int*)values[4]
> $14 = 1

so it all seems right (is it?), but clearly I would not be writing if it went well.
Is my hope to use libffi for calling snprintf a vein one?

Thank you.

> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7446892 in vsnprintf () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007ffff7446892 in vsnprintf () from /lib64/libc.so.6
> #1  0x00007ffff7424ff2 in snprintf () from /lib64/libc.so.6
> #2  0x000000000040b660 in ffi_call_unix64 () at ../src/x86/unix64.S:76
> #3  0x000000000040b02f in ffi_call (cif=0x7fffffffc640,
>     fn=0x401250 <snprintf@plt>, rvalue=0x7fffffffc66c, avalue=0x663c230)
>     at ../src/x86/ffi64.c:525

             reply	other threads:[~2015-04-24 21:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 21:54 Bruce Korb [this message]
2015-04-24 23:24 ` Richard Henderson
2015-04-25 17:31   ` Bruce Korb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553ABBA4.40505@gmail.com \
    --to=bruce.korb@gmail.com \
    --cc=libffi-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).