search for: cabecinhas

...sassemble whole files? Or should I create another project for that? How do you suggest reading the files? Re-implementing the reading stuff? "Steal" from lldb (I don't know how self-contained the plug-in may be… It could require a big part of lldb)? Any other ideas? Regards, Filipe Cabecinhas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110119/6b2b6b1f/attachment.html>

On Wed, Jan 19, 2011 at 6:00 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Hi, > I want to extend llvm-mc to make it disassemble whole files, instead of > sequences of bytes. > Most of the work to read from a Mach-O file is already done by lldb, but > that is outside llvm's repository and not useful to llvm-mc (as fa...

Hi, LLVM-gcc can't recognize this option, don't know why, because the gcc in Mac OS X (quite old, compared to 4.2) can recognize it. - Filipe Cabecinhas

...triction looks reasonable: A record starts with a code. The code > can be encoded as a literal or be part of the abbreviation. > > There is probably not a lot of value in supporting a code embedded in the > first element of an array or blob. > > On 23 January 2015 at 16:47, Filipe Cabecinhas <filcab at gmail.com> wrote: > >> Hi all! >> >> Fuzzing llvm's bitcode reader, I found a problem where the reader assumes >> that the first field in an abbreviation will not be an array or a blob (and >> asserts otherwise). >> >> I don't kn...

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote: >> Not when dead store happens in an external DSO where compiler can't detect >> it (same applies for single references). > > Do you mean the ones between the DSO and the instrumented code? >

On Jun 5, 2008, at 3:15 AM, Filipe Cabecinhas wrote: > LLVM-gcc can't recognize this option, don't know why, because the gcc > in Mac OS X (quite old, compared to 4.2) can recognize it. The option is no longer needed and hasn't been for quite some time. Just remove it.

Hi, On 5 Jun, 2008, at 19:12, Mike Stump wrote: > The option is no longer needed and hasn't been for quite some time. > Just remove it. So, even in gcc 4.0.1 (the current for Mac OS X), it doesn't do anything? Thanks for the reply, - Filipe Cabecinhas

Filipe Cabecinhas wrote: > Just a thought... How are you going to port llvm so it doesn't use libc? > Valgrind uses the same resources as the running program, so it can't use > the system libc's malloc nor any other functions so it doesn't get > "confused". I think you coul...

+1 On Wed, May 4, 2016 at 3:10 AM, Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Wed, May 4, 2016 at 9:35 AM, Ronan KERYELL via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >>>>>> On Tue, 3 May 2016 16:36:01 -0400, Rafael Espíndola via llvm-dev < > llvm-dev at...

On Sun, Feb 7, 2010 at 12:30 AM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Hi, > > Try these scripts to build llvm and llvm-gcc. It's the ones I use and I > managed to get them to work when I saw another build script using those > CFLAGS. > > They compile llvm and stuff using only x86_64, but you can then gener...

Hi, Just a thought... How are you going to port llvm so it doesn't use libc? Valgrind uses the same resources as the running program, so it can't use the system libc's malloc nor any other functions so it doesn't get "confused". Regards and let's hope this project is accepted :-) F Owen Anderson wrote: > Rodrigo, > > On Mar 20, 2009, at 8:41 AM,

Hi all! Fuzzing llvm's bitcode reader, I found a problem where the reader assumes that the first field in an abbreviation will not be an array or a blob (and asserts otherwise). I don't know if this is expected (but not documented) or not. The documentation, to me, reads like it doesn't disallow it, but we might be assuming all abreviations start with a full record, which would make

On Tue, Apr 19, 2016 at 10:18 AM Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Apr 17, 2016 at 10:46 PM, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > TL;DR: We plan to build a suite of compiler-based dynamic instrumentation > > tools for analyzing targeted perfo...

...r the part that I was trying to use, but there's probably a > lot to fix for it to fully work. > > Cheers, > - Stan > > On Wed, May 4, 2016 at 4:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> +1 >> >> On Wed, May 4, 2016 at 3:10 AM, Filipe Cabecinhas via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> On Wed, May 4, 2016 at 9:35 AM, Ronan KERYELL via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> >>>>>> On Tue, 3 May 2016 16:36:01 -0...

On Tue, Apr 19, 2016 at 1:18 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Thanks for proposing this. It seems like it might be an interesting > tool for us too. But this proposal seems a bit hand-wavy, and I think > it's missing some crucial info before we start heading this way. > > At least for the tools you are...

...t to fully work. >>> >>> Cheers, >>> - Stan >>> >>> On Wed, May 4, 2016 at 4:21 PM, David Blaikie <dblaikie at gmail.com> >>> wrote: >>> >>>> +1 >>>> >>>> On Wed, May 4, 2016 at 3:10 AM, Filipe Cabecinhas via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Wed, May 4, 2016 at 9:35 AM, Ronan KERYELL via llvm-dev >>>>> <llvm-dev at lists.llvm.org> wrote: >>>>>...

...nly one offset does not seem enough to > handle generic cases. > > -----Original Message----- > From: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] > Received: Dienstag, 12 Sep. 2017, 9:57 > To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] > CC: Filipe Cabecinhas [me at filcab.net] > Subject: [llvm-dev] RFC phantom memory intrinsic > > Hi, > For PR21780 solution, I plan to add a new functionality to restore > memory operations that was once deleted, in this particular case it is > the load operations that were deleted by InstCombine, pleas...

Hi all, As we all know, ASan prints all diagnostics information to stderr. It also has some API to get information about addresses, etc (useful for debugging), which prints information to stderr. These features require a live process, and the ability to call functions in the process. It also forces a user to do multiple target calls to run functions, which might be slow (or impossible, in the

Indeed. But the problem here is that Dinar is trying to keep information after a load/store is removed by instcombine For example: v4sf v = {p[0], p[1], p[2], p[3]}; v4sf v2 = shuffle(v, 0, 0, 2, 2); Some pass comes in and removes the p[3] and p[1]. Now you have smaller code, but lost the ability to use a vector load for all those values + shuffle. The code got scalarized because we lost the

...le generic cases. >>> >>> -----Original Message----- >>> From: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] >>> Received: Dienstag, 12 Sep. 2017, 9:57 >>> To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] >>> CC: Filipe Cabecinhas [me at filcab.net] >>> Subject: [llvm-dev] RFC phantom memory intrinsic >>> >>> Hi, >>> For PR21780 solution, I plan to add a new functionality to restore >>> memory operations that was once deleted, in this particular case it is >>> the load op...