similar to: [RFC] Proposal: llvm-tapi, adding YAML/stub generation for ELF linking support

Right. Usually you wouldn't want to write a .tbe from scratch, but for the sake of linking against a DSO you might only have access to a .tbe stub that was produced from the DSO. This specific functionality becomes critical when DSOs only used for linking are replaced entirely by .tbe stubs because at a SDK level the complete DSO isn't needed. This is what Apple has done to significantly

Since the goal is to start llvm-tapi more or less from scratch, I feel the best approach initially is to focus on the structure as a key point of feedback in initial reviews. Once the foundations are set, integrating Mach-O TAPI in parallel with the ELF implementation should be relatively straightforward. The features outside of stubbing aren't as appealing for ELF, so I probably won't be

Absolutely. The goal of the tool is to produce both textual and binary DSO stubs. This means you could take a DSO, produce a textual stub, modify it however you wish, and then produce a linkable binary stub from that modified .tbe. That, or you could bypass the textual portion altogether and just produce binary stubs from DSOs. While the textual format is useful, the goal is to make the tool

Oof, I didn't think about Clang not being in the same place. Perhaps we could put this in clang-tools-extra to solve that? As for the unification of the code bases. I was assuming we didn't want to just throw a ton of code over the wall anyway so the merge was going to need to be reviewed chunk by chunk anyhow. Support for the two formats should be possible to add in parallel (although, I

On Thu, Sep 27, 2018 at 3:12 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Sep 27, 2018 at 2:42 PM Armando Montanez via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Since the goal is to start llvm-tapi more or less from scratch, I feel >> the best approach initially is to focus on the structure as a key >> point of

<div dir='auto'>Maybe LLD is lagging behind, but is the TAPI stuff that's landed close enough to the original such that Apple cctools could be modified to use it?<div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto"><br></div><div

Great to hear, thanks! On Thu, Sep 20, 2018 at 1:56 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > A member of my team +Armando Montanez <amontanez at google.com> is going to > drop a proposal for the ELF part of this soon (like sometime next week) and > will be working on the implementation. I'll be one of the reviewers for > anything that comes out of that so

Was there any progress in the upstreaming effort? I'd be interested in having lld be able to link against tbd files, and I think it'd be cool if libtool -static could write tbd files (similar to thin archives on linux) since that should make archiving much faster. Juergen, maybe uploading your initial patch to phabricator instead of attaching might get more traction? On Wed, Apr 25, 2018

Hi @ll, Over the past years I have been looking into how to reduce the size of the SDK that ships with Xcode and how to improve build times for the overall OS inside Apple. The result is a tool called TAPI, which is used at Apple for all things related to text-based dynamic library files (.tbd). What are text-based dynamic library files? Text-based dynamic library files (TBDs) are a textual

Hi Juergen, At a minimum I think adding the support to libobject, etc so the various llvm tools can read or even write files from/for OSX should be fairly non-controversial so how about go ahead and do that first (I'll happily review if you'd like) and then we can go from there to do anything else with TAPI and llvm? Sound good? -eric On Thu, Sep 7, 2017 at 5:01 PM Juergen Ributzka via

Hey, I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have a prototype in golang that just spins up an instance of llvm-symbolizer

Hi Jake. Thanks for the info. Where can I keep up to date on the symbolizer status? Our symbolizer is provided by the Myriad vendor and integrated into its host test environment. It doesn't do much: just look for PC string patterns and symbolize them using addr2line. Thanks, Walter On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Hey, > I

On Fri, Jun 2, 2017 at 1:01 PM Sean Silva <chisophugis at gmail.com> wrote: > On Thu, Jun 1, 2017 at 8:47 PM, Petr Hosek via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This is a followup to the discussion that started in D28791. To provide >> the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle >> symbol is mandated by C++

This is a followup to the discussion that started in D28791. To provide the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle symbol is mandated by C++ ABI with a value which is an address in one of the object's segments, and as such this symbol has to be included statically and cannot be a part of a shared library. Different systems provide it differently: 1. On

I have ported ASan in LLVM to Myriad RTEMS, and I would like to upstream the port. Below is the design doc. Feedback welcome. https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM The port is expected to work with modified versions of RTEMS and newlib. I have a git repo with changes to those projects, that I can make available if there is interest. Here is the patch

On Mon, Jun 24, 2019 at 3:37 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > disclaimer: I work at Google so don't take my +1 as an independent vote > forward. > > We would like to use this on Fuchsia and I am particularly interested in > creating a dynamic linking library for ELF with Roland McGrath's guidance. > We spoke about creating a library for writing

Hi, This is a bit off-topic, but still related to telephony. Is there a barebones TAPI driver that exists that would allow me to call up a command line with, as parameter, the number to dial. For exemple, Outlook integrates with TAPI, so that TAPI driver would allow me to call my own app with the phone number as argument. ex when clicking on 555-555-5555: the TAPI driver would call

Hi, To make a long story short, I can't install any TAPI driver on my XP platform. A. Within Config Panel|Modems and Telephony options|Advanced parameters, I've got a list of 7 TAPI drivers. Among them is Omniis TAPI driver for Asterisk. B. I can properly configure this driver (line, context, ...). C. When I open Outlook 2002 Contacts panel, I can select "Call this contact"

I've been testing the debug version of AstTAPI, which worked for a few calls, then a bit later in the day (and ever since), when the call is hung up, the TAPI client doesn't get notified. Looking at the server logs, The TAPI message that is sent upon hangup, isn't being sent. exten => h,1,UserEvent(TAPI|TAPIEVENT: LINE_CALLSTATE LINECALLSTATE_IDLE) This is in the same context as

I just installed tapi and some app called identapop pro. I havent tested incoming calls yet but so far, I cant get calls out using outlooks. I configured TAPI for asterisk inside outlooks and I set TAPI to these configs: TAPI connects using the manager to asterisk without problems. As channels I configure this: User channel: SIP/myphone and the phone actually rings when I tell outlook to dial