[llvm-dev] [Proposal][Debuginfo] dsymutil-like tool for ELF.
Alexey Lapshin via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 2 10:19:26 PST 2020
On 02.11.2020 21:12, David Blaikie wrote:
>
>
> On Mon, Nov 2, 2020 at 2:26 AM Alexey Lapshin <avl.lapshin at gmail.com
> <mailto:avl.lapshin at gmail.com>> wrote:
>
>
> On 02.11.2020 04:11, David Blaikie wrote:
>> I think if we're in the realm of DWARF extensions a whole bunch
>> of other considerations come into it (& indeed, your suggested
>> proposal may be a good one - but I think it's a very wide problem
>> space once we're considering DWARF extensions). Mostly I was
>> making arguments/suggestions/thoughts on the basis of being
>> compatible with all existing DWARF producers.
>
> the described scenario does not assume DWARF extensions. global
> type table is not new DWARF construction. This is an artificial CU
> keeping all types. That solution would be compatible with existing
> DWARF consumers/produces.
>
> Sorry, guess I'm not following. Maybe this conversation's getting a
> bit too abstract/theoretical/forward looking for me right now - no
> worries. Happy to chat more about it, but might be easier to focus on
> the immediate steps forward for now & tackle this when it's the thing
> you're planning to work on? (if I'm understanding correctly that this
> isn't a direction you're thinking to try right now)
Right, that is not what I am going to do immediately. My current plan,
is to preserve current types processing but make it multi-thread(more
multi-thread than it already is). Above ideas are for future plans.
Let`s discuss them later. Thank you, for the comments.
Alexey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201102/26e74bdb/attachment.html>
More information about the llvm-dev
mailing list