search for: hackily

...t. Does this mean that libFlac or just the commandline tool is limited to 24 bit? We would love to use FLAC as a total replacement for WAV files in our product (in exported song and instrument content), but really need to have 32bit support, as our internal sample format is 32 bit. I already hackily tried to change FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE to 32u and ran some tests using libFlac. All seemed to work well, so this limitation is maybe (no longer?) needed? Greets, eduard

...24 >> bit? >> >> We would love to use FLAC as a total replacement for WAV files in our >> >> product (in exported song >> and instrument content), but really need to have 32bit support, as >> our internal sample format >> is 32 bit. >> I already hackily tried to change >> FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE to 32u and ran >> some tests using libFlac. All seemed to work well, so this limitation >> is maybe (no longer?) >> needed? > > if this works for you, then you are lucky! the missing parts > are 32-bit ha...

...that NotifyFunctionEmitted is gone (understandably) and so I hook NotifyObjectEmitted. I then run through all the function symbols and dump them as before. Yay. Except that in MCJIT terms the linking hasn't happened, so all the globals and external functions are all zeros at this point. (If I hackily observe the same code later on I see the linker has appropriately populated these addresses). This makes my nicely annotated code a little unreadable, unfortunately. Does anyone have any suggestions as to how I might get to disassemble the post-linked code? Thanks once again! -matt On Wed, Sep...

...>> (understandably) and so I hook NotifyObjectEmitted. I then run through >> all the function symbols and dump them as before. Yay. Except that in >> MCJIT terms the linking hasn't happened, so all the globals and >> external functions are all zeros at this point. (If I hackily observe >> the same code later on I see the linker has appropriately populated >> these addresses). This makes my nicely annotated code a little >> unreadable, unfortunately. >> >> Does anyone have any suggestions as to how I might get to disassemble >> the post...

This affects the XMMS plugin. configure.in has this test: AC_CHECK_TYPES(socklen_t, [], []) And src/plugin_xmms/http.c is the only consumer: #ifndef HAVE_SOCKLEN_T typedef unsigned int socklen_t; #endif Together this looks bogus to me. The configure check looks for socklen_t in the default headers. If it isn't found there, socklen_t will be typedef'ed. However, at least on

Hi Jim, Thanks for a very quick reply! That indeed does the trick! Presumably the default has changed in 3.5 to be a "generic" CPU instead of the native one? If that's the case I wonder why: especially when JITting it really only makes sense to target the actual CPU - unless I'm missing something? :) Thanks again, Matt On Wed, Sep 17, 2014 at 2:16 PM, Jim Grosbach

...ere are actual arguments to that hypercall and the toolstack only initialises the arguments which are used. However there is no space in the DEFN_PRE_TEMPLATE prototype to allow this to be communicated from syswrap-xen.c back to syswrap-linux.c. Since a hypercall can have at most 5 arguments I have hackily stolen ARG8 for this purpose. --- configure.in | 19 + coregrind/Makefile.am | 8 +- coregrind/m_debuginfo/debuginfo.c | 9 + coregrind/m_syswrap/priv_syswrap-xen.h | 10 + coregrind/m_syswrap/syswrap-linux.c | 107 ++++- coregrind/m_sy...

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,