| Message ID | 20160309050812.GK2377@pxdev.xzpeter.org |
|---|---|
| State | New |
| Headers | show |
On 09/03/2016 06:08, Peter Xu wrote: > pxdev:bin# gcc -v > Using built-in specs. > COLLECT_GCC=/bin/gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) > > Do you know why "might not be inlinable"? Failed to figure it out > myself as mentioned in cover letter.. It's just a difference in compiler versions. But ARRAY_SIZE should be enough to fix it. Paolo
On Wed, Mar 09, 2016 at 08:53:19AM +0100, Paolo Bonzini wrote: > > > On 09/03/2016 06:08, Peter Xu wrote: > > pxdev:bin# gcc -v > > Using built-in specs. > > COLLECT_GCC=/bin/gcc > > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper > > Target: x86_64-redhat-linux > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux > > Thread model: posix > > gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) > > > > Do you know why "might not be inlinable"? Failed to figure it out > > myself as mentioned in cover letter.. > > It's just a difference in compiler versions. But ARRAY_SIZE should be > enough to fix it. It's dynamically allocated in stack, can we still use ARRAY_SIZE in this case? Maybe for this case, best to use both stack and heap? malloc only if buffer big enough. Peter
Peter Xu <peterx@redhat.com> writes: > On Wed, Mar 09, 2016 at 08:53:19AM +0100, Paolo Bonzini wrote: >> >> >> On 09/03/2016 06:08, Peter Xu wrote: >> > pxdev:bin# gcc -v >> > Using built-in specs. >> > COLLECT_GCC=/bin/gcc >> > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper >> > Target: x86_64-redhat-linux >> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux >> > Thread model: posix >> > gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) >> > >> > Do you know why "might not be inlinable"? Failed to figure it out >> > myself as mentioned in cover letter.. >> >> It's just a difference in compiler versions. But ARRAY_SIZE should be >> enough to fix it. > > It's dynamically allocated in stack, can we still use ARRAY_SIZE in > this case? ARRAY_SIZE(x) is defined as (sizeof(x) / sizeof((x)[0])). Works when x is of array type (variable length array is fine). Screws up when x is of *pointer* type. C99 6.5.3.4: The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand. The result is an integer. If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated and the result is an integer constant. [...]
On Wed, Mar 09, 2016 at 09:34:50AM +0100, Markus Armbruster wrote: > Peter Xu <peterx@redhat.com> writes: > > It's dynamically allocated in stack, can we still use ARRAY_SIZE in > > this case? > > ARRAY_SIZE(x) is defined as (sizeof(x) / sizeof((x)[0])). Works when x > is of array type (variable length array is fine). Screws up when x is > of *pointer* type. > > C99 6.5.3.4: > > The sizeof operator yields the size (in bytes) of its operand, which > may be an expression or the parenthesized name of a type. The size > is determined from the type of the operand. The result is an > integer. If the type of the operand is a variable length array > type, the operand is evaluated; otherwise, the operand is not > evaluated and the result is an integer constant. Good to know it. Thanks! :) However, ARRAY_SIZE() still cannot help solving the unbounded stack issue, right? Peter
Peter Xu <peterx@redhat.com> writes: > On Wed, Mar 09, 2016 at 09:34:50AM +0100, Markus Armbruster wrote: >> Peter Xu <peterx@redhat.com> writes: >> > It's dynamically allocated in stack, can we still use ARRAY_SIZE in >> > this case? >> >> ARRAY_SIZE(x) is defined as (sizeof(x) / sizeof((x)[0])). Works when x >> is of array type (variable length array is fine). Screws up when x is >> of *pointer* type. >> >> C99 6.5.3.4: >> >> The sizeof operator yields the size (in bytes) of its operand, which >> may be an expression or the parenthesized name of a type. The size >> is determined from the type of the operand. The result is an >> integer. If the type of the operand is a variable length array >> type, the operand is evaluated; otherwise, the operand is not >> evaluated and the result is an integer constant. > > Good to know it. Thanks! :) > > However, ARRAY_SIZE() still cannot help solving the unbounded stack > issue, right? Measuring the size of the array doesn't change the size of the array :)
On 09/03/2016 09:07, Peter Xu wrote: >>> > > pxdev:bin# gcc -v >>> > > Using built-in specs. >>> > > COLLECT_GCC=/bin/gcc >>> > > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper >>> > > Target: x86_64-redhat-linux >>> > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux >>> > > Thread model: posix >>> > > gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) >>> > > >>> > > Do you know why "might not be inlinable"? Failed to figure it out >>> > > myself as mentioned in cover letter.. >> > >> > It's just a difference in compiler versions. But ARRAY_SIZE should be >> > enough to fix it. > It's dynamically allocated in stack, can we still use ARRAY_SIZE in > this case? > > Maybe for this case, best to use both stack and heap? malloc only if > buffer big enough. If you look at users, they only write about 20 bytes at most. My suggestion is to use your patch, and replace assert(__BUF_SIZE >= n); with assert(n < ARRAY_SIZE(tmp)); Then you don't need the #define. Paolo
On Wed, Mar 09, 2016 at 01:59:03PM +0100, Paolo Bonzini wrote: > If you look at users, they only write about 20 bytes at most. My > suggestion is to use your patch, and replace > > assert(__BUF_SIZE >= n); > > with > > assert(n < ARRAY_SIZE(tmp)); > > Then you don't need the #define. Okay. Will fix and post another one. Thanks. Peter
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c index 44b6f8c..961fd78 100644 --- a/hw/usb/hcd-xhci.c +++ b/hw/usb/hcd-xhci.c @@ -694,7 +694,7 @@ static inline void xhci_dma_read_u32s(XHCIState *xhci, dma_addr_t addr, } } -static inline void xhci_dma_write_u32s(XHCIState *xhci, dma_addr_t addr, +static QEMU_ARTIFICIAL void xhci_dma_write_u32s(XHCIState *xhci, dma_addr_t addr, uint32_t *buf, size_t len) { int i;