similar to: Dead (or untested?) code in the gold plugin

When I build LLVM 2.6 after configuring it with the --with-binutils-include option so it points to the gold plugin src/include directory, I get the errors below. I used "cvs -z 9 -d :pserver:anoncvs at sourceware.org:/cvs/src co src" to check out the gold-plugin, as is documented on llvm.org. -------------------------- make[2]: Entering directory

GCC LTO works ok for the test case with both bfd and gold linker. David On Tue, Oct 4, 2016 at 6:58 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:15 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote:

Fresh off the presses, completely untested... use at your own risk... -hpa -------------- next part -------------- A non-text attachment was scrubbed... Name: tmpfs-root.patch Type: text/x-patch Size: 1493 bytes Desc: not available Url : http://www.vas.nu/pipermail/klibc/attachments/20050404/dd420f06/tmpfs-root.bin

The attached patch attempts to implement Theora's cropping frame in Cortado. I make no claim that it is likely to work, as I have no clue how to build and test Jheora/Cortado. Please test. Thank you. I can at least confirm that CropImageFilter and FilteredImageSource were present in JDK 1.1. Performance impact in the absence of cropping should be negligible. With cropping, there might be

On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > iovec addresses coming from vhost are assumed to be > pre-validated, but in fact can be speculated to a value > out of range. > > Userspace address are later validated with array_index_nospec so we can > be sure kernel info does not leak through these addresses, but vhost > must also not leak userspace info outside the allowed

On 2019/9/9 ??10:45, Michael S. Tsirkin wrote: > On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote: >> On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: >>> iovec addresses coming from vhost are assumed to be >>> pre-validated, but in fact can be speculated to a value >>> out of range. >>> >>> Userspace address are later validated with

The two patches attached allow 9p filesystems to be mounted and listed. Note that I did *not* test the new list-9p function, because I don't have a guest with a new enough kernel handy. 9p filesystems are not included in the output of list-filesystems. Because a lot of existing code feeds the output of list-filesystems directly into the input of mount-options, mount-ro or (even worse) plain

On Tue, Sep 10, 2019 at 09:52:10AM +0800, Jason Wang wrote: > > On 2019/9/9 ??10:45, Michael S. Tsirkin wrote: > > On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote: > > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > > > iovec addresses coming from vhost are assumed to be > > > > pre-validated, but in fact can be speculated to a value

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the

On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not

On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not

Random old patch that I had in my queue. Posting it as a backup, it is still untested. Rich.

Hi Duncan, Thanks for your reply. I did try the method suggested by you. I got a foo.bc with -emit-llvm switch. llc on foo.bc gets me the same assertion failure, as you pointed out. Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and bugpoint-reduced-function.bc. My previous experience is that if I compile either if them, I would get the same failure as I did with foo.bc. That is

On Mar 4, 2009, at 1:33 PM, S. Bharadwaj Yadavalli wrote: > Hi Duncan, > > Thanks for your reply. > > I did try the method suggested by you. I got a foo.bc with -emit- > llvm switch. llc on foo.bc gets me the same assertion failure, as > you pointed out. > > Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and > bugpoint-reduced-function.bc. My

MemoryBuffer requires that its buffer be NULL terminated. This is handy for some users, but it is a hard requirement for some cases. For example, currently I get the following valgrind error when doing LTO and fetching an archive member: at 0x6DAC36E: llvm::MemoryBuffer::init(char const*, char const*) (MemoryBuffer.cpp:50) Address 0x5fecea0 is 0 bytes after a block of size 464 alloc'd

Hi Bharadwaj, > I get the following error during compilation using the LLVM cross-compiler > (x86_64->arm). > > error: nested functions are disabled, use -fnested-functions to re-enable yes, nested functions are disabled by default in llvm-gcc (not sure why - maybe a historical hang over from the days when they were not supported?). > With -fnested-functions switch, I get the

I get the following error during compilation using the LLVM cross-compiler (x86_64->arm). error: nested functions are disabled, use -fnested-functions to re-enable With -fnested-functions switch, I get the following error: <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&):

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached