[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