search for: pahtak

> On Jan 17, 2017, at 12:33 PM, Stephen Checkoway <s at pahtak.org> wrote: > > >> On Jan 17, 2017, at 10:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Actually you have to opt-in instead of opt-out right now, and I encourage you to try it if you’re contributing to LLVM: http://llvm.org/docs/GettingSt...

On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: > > This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution. > Thanks for the link, completely missed when googled the issue. I think no consensus was reached (I cannot find any commit in the...

> On Jan 17, 2017, at 12:44 PM, Stephen Checkoway <s at pahtak.org> wrote: > > >> On Jan 17, 2017, at 14:39, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >>> On Jan 17, 2017, at 12:33 PM, Stephen Checkoway <s at pahtak.org> wrote: >>> >>> >>>> On Jan 17, 2017, at 10:11,...

On Nov 20, 2013, at 4:11 PM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: >> >> This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution. >> > > Thanks for the link, completely missed when googled the issue. I think > no consensus was reached (I...

...Opcode() == X86::CALL64r) { if (Inst.getOperand(0).getReg() == X86::RIP) { // ... } } E.g., exposing some of the tablegened enums in X86GenRegisterInfo.inc and X86GenInstrInfo.inc would be very handy. Steve > > > On Oct 28, 2013 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of cou...

On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: >> >> On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >>> But gold has at most 2 objects loaded at any time. >> >> Are you sure about that? I haven't looked into it but while building Chromium...

On Nov 15, 2013, at 11:16 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Taking a really quick at the gold code it looks like it tries to keep > 8176 files open. I would suggest putting a breakpoint in > Descriptors::close_some_descriptor and checking why it is failing to > close the files. That is a lot of file descriptors to keep open. It's well above my

Just a guess, but it might have something to do with the chrome build using thin archives. On 15 November 2013 11:30, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 15, 2013, at 11:16 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> Taking a really quick at the gold code it looks like it tries to keep >> 8176 files open. I would suggest putting a breakpoint in >> Descriptors::close_some...

Can't you just include the generated files? What different way would you like them exposed? On Mon, Oct 28, 2013 at 11:23 AM, Stephen Checkoway <s at pahtak.org> wrote: > > On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> > wrote: > > > See the source here: > https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. > It looks like getRegisterName migh...

On Aug 13, 2013, at 4:51 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > Getting CMake up to the standard where it supports a superset of what autoconf supports is required for dropping autoconf Is there a list somewhere of what autoconf supports that CMake does not (and that people care about)? It could be that people simply don't know what's missing since, as you

Taking a really quick at the gold code it looks like it tries to keep 8176 files open. I would suggest putting a breakpoint in Descriptors::close_some_descriptor and checking why it is failing to close the files. On 15 November 2013 11:03, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: >>> >>> On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola...

On Nov 20, 2013, at 1:26 PM, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 20, 2013, at 4:11 PM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > >> On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: >>> >>> This has come up before <https://groups.google.com/for...

...at you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's a member, it's public.) PS Sorry for the duplicate, Stephen. I forgot to CC the list. On Oct 28, 2013 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > I'm iterating over MCInsts and I'd like to examine particular > instructions. For example, I'd like to look at all x86 CALL64m > instructions. I may be missing something, but it seems like my only option > is to use MCInstPrinter::getOpcodeName and compare...

On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> But gold has at most 2 objects loaded at any time. > > Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: > >...

I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string

On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > But gold has at most 2 objects loaded at any time. Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: ../../third_party/gold/gold64: fatal error: out of file descriptors and couldn't close any clang: error: linker command failed with exit code 1

On Feb 28, 2016 12:08 AM, "Stephen Checkoway" <s at pahtak.org> wrote: > > > > > On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > The problem is that llvm-mc always compiles "jmp" this as short jump, no matter where the target is. Hence my question. I dont know if there is an...

On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: >> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants. >> >> The...

> On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The problem is that llvm-mc always compiles "jmp" this as short jump, no matter where the target is. Hence my question. I dont know if there is any way to change this behavior. Looks like a bug to me so far. It isn't. It's just created some assembly which, when assembled, may

Hi, I am trying to link archives built by llvm-ar with other bitcode files, using llvm-link. But llvm-link seems unable to read files produced by llvm-ar. Also, clang seems unable to read files produced by llvm-ar. Am I doing something wrong or is this the expected behavior? Is there any work-around? Thanks. -Apala