Page MenuHomePhabricator

ayermolo (Alexander Yermolovich)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 25 2020, 4:03 PM (13 w, 2 d)

Recent Activity

Fri, Nov 20

ayermolo added inline comments to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Fri, Nov 20, 12:24 PM · Restricted Project

Thu, Nov 19

ayermolo added inline comments to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Thu, Nov 19, 5:22 PM · Restricted Project
ayermolo added inline comments to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Thu, Nov 19, 3:23 PM · Restricted Project
ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Thu, Nov 19, 11:07 AM · Restricted Project
ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Thu, Nov 19, 10:48 AM · Restricted Project

Wed, Nov 18

ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 5:00 PM · Restricted Project
ayermolo added inline comments to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 4:49 PM · Restricted Project
ayermolo added inline comments to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 4:40 PM · Restricted Project
ayermolo added inline comments to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 2:16 PM · Restricted Project
ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 2:14 PM · Restricted Project
ayermolo added inline comments to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 12:38 PM · Restricted Project
ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 12:35 PM · Restricted Project
ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Wed, Nov 18, 12:32 PM · Restricted Project

Tue, Nov 17

ayermolo added a comment to D90507: [Driver] Add DWARF64 flag: -gdwarf64.

It looks like lld/test/COFF/lto-new-pass-manager.ll.obj was added to the patch by accident and should be removed.

Tue, Nov 17, 10:04 AM · Restricted Project

Mon, Nov 16

ayermolo added a comment to D90507: [Driver] Add DWARF64 flag: -gdwarf64.

This change covers non-LTO cases. For LTO, I think we would need to pass it from driver to LTO. Something like this: tools::addLTOOptions -> lld -> lto::Config (Config->TargetOptions->MCTargetOptions) ->LTO Backend.

Mon, Nov 16, 5:12 PM · Restricted Project
ayermolo added a comment to D90507: [Driver] Add DWARF64 flag: -gdwarf64.

Hi @ayermolo, do you think this might be triggered by D82756? (my only upstream patch ATM)

Mon, Nov 16, 5:11 PM · Restricted Project
ayermolo added a comment to D91404: RFC: [ELF] Add --dwarf32-before-dwarf64 to place DWARF32 input sections before DWARF64.
In D91404#2393750, @avl wrote:

Well, this is a bit different from my original idea but is an overall good heuristic for many of the debug sections. It works for .debug_info, which is one of the biggest sections; it does not work for .debug_line, though, which is not that big as .debug_info, but potentially might become problematic in the (distant) future; it also does not work for .debug_abbrev, .debug_addr, .debug_ranges, and some others, which are usually not that big. However, the patch should be extended to support .debug_str, which can be even larger than .debug_info.

Would it be useful if decision done for the debug_info section would also be applied to all other debug sections from the same object file?

Well, this is a bit different from my original idea but is an overall good heuristic for many of the debug sections. It works for .debug_info, which is one of the biggest sections; it does not work for .debug_line, though, which is not that big as .debug_info, but potentially might become problematic in the (distant) future; it also does not work for .debug_abbrev, .debug_addr, .debug_ranges, and some others, which are usually not that big. However, the patch should be extended to support .debug_str, which can be even larger than .debug_info.

We either mark InputFile or InputSectionBase referenced by a 64-bit absolute relocation. I prefer InputBaseBase which is more direct (we have spare bits in SectionBase after keepUnique).

DWARF v4 .debug_str is referenced by .debug_info's non-first relocation. The InputSectionBase based referenced bit approach does not work. So maybe we have to use InputFile.

Mon, Nov 16, 4:53 PM · Restricted Project

Thu, Nov 12

ayermolo updated subscribers of D90507: [Driver] Add DWARF64 flag: -gdwarf64.

@jansvoboda11 Can you take a look? The failing test is unrelated it seems. Fails locally even without my change.

Thu, Nov 12, 6:16 PM · Restricted Project

Mon, Nov 9

ayermolo added a comment to D90507: [Driver] Add DWARF64 flag: -gdwarf64.

The failure seems unrelated to my changes. Trying locally it fails with latest upstream even without my changes.

Mon, Nov 9, 4:10 PM · Restricted Project
ayermolo added a comment to D90507: [Driver] Add DWARF64 flag: -gdwarf64.
  1. The patch needs tests to check the added functionality.
  2. DWARF64 can be generated only for a limited number of targets. There should be diagnostics for invalid switch combinations to prevent misuse. @MaskRay mentioned that in the patch for llc, D87011#2254749, but that makes a lot more sense for user-level tools.
Mon, Nov 9, 3:28 PM · Restricted Project
ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Mon, Nov 9, 3:27 PM · Restricted Project
ayermolo added a comment to D87011: [DebugInfo] Add the -dwarf64 switch to llc and other internal tools (4/19)..

At least in LLD, it's not quite as simple as being added after the user's code: if a library appears on the link line it will be included in the output order as soon as it is determined it is needed. Thus if you have have three modules 1.o, 2.o, and 3.o, with 3.o in an archive 3.a and 1.o requiring 3.o, you end up with an output order of 1.o 3.o 2.o if the input order was 1.o 3.a 2.o or 3.a 1.o 2.o or an output order of 1.o 2.o 3.o if the input order was 1.o 2.o 3.a. In fact, with use of the --undefined linker switch, you can even force 3.o to appear first.

I accept using --undefined or rearranging the command-line order is less than ideal, but I'm really not convinced LLD should have any place in parsing the DWARF to determine output order. Furthermore, it's not even a reliable solution - if the objects built with DWARF32 (potentially all of which might have come from libraries) are large enough, no amount of reordering will fix the behaviour. I think users who need DWARF64 in their libraries are just going to have to request DWARF64 versions of the libraries, if the --undefined and reordering command line options are insufficient.

I'd guess that for a large-scale project the recommendation to use -u would be unrealistic. We are talking about projects where debugging information in a single section can easily go beyond the 4GiB limit; it is impossible for the developer to adjust the command line manually.

By the way, from a semantic point of view, I don't think it matters if the DWARF is in a different order to the data it represents - I'm just concerned about the maintenance and performance burden of having to parse the DWARF to achieve this reordering.

There is no need to parse the debug info sections. Reading only the first 4 bytes of .debug_info is enough to assess the format (there might be input files with format intermixing, but we can ignore them in the sack of simplicity). And we do not need any automatic sorting if the size of an output section is less than 4GiB.

Exactly. Not to mention, I think for users that actually worry about 4Gig limit they have pretty complex build system that will need to be modified to get build order right. Probably doable, but looking at overall compilation pipeline, is it really the best approach? Within lld we don't have to parse entire debug section, just read few bytes in each CU to determine if it's 32 or 64 bit.
Yes theoretically it is possible that there are just so many third party libraries that they will over flow 4gig by themselves, but I think common case is they will be under 4 gigs.

FWIW, this is probably a big enough discussion to deserve it's own review, probably even it's own llvm-dev thread. My personal take would be: Unless there's a specific user who needs this, probably not worth building it. If you personally have a need or support users who need it, that swings the discussion a fair bit into "what's the best way we can help these users".

Mon, Nov 9, 10:42 AM · debug-info, Restricted Project

Fri, Nov 6

ayermolo added a comment to D87011: [DebugInfo] Add the -dwarf64 switch to llc and other internal tools (4/19)..

At least in LLD, it's not quite as simple as being added after the user's code: if a library appears on the link line it will be included in the output order as soon as it is determined it is needed. Thus if you have have three modules 1.o, 2.o, and 3.o, with 3.o in an archive 3.a and 1.o requiring 3.o, you end up with an output order of 1.o 3.o 2.o if the input order was 1.o 3.a 2.o or 3.a 1.o 2.o or an output order of 1.o 2.o 3.o if the input order was 1.o 2.o 3.a. In fact, with use of the --undefined linker switch, you can even force 3.o to appear first.

I accept using --undefined or rearranging the command-line order is less than ideal, but I'm really not convinced LLD should have any place in parsing the DWARF to determine output order. Furthermore, it's not even a reliable solution - if the objects built with DWARF32 (potentially all of which might have come from libraries) are large enough, no amount of reordering will fix the behaviour. I think users who need DWARF64 in their libraries are just going to have to request DWARF64 versions of the libraries, if the --undefined and reordering command line options are insufficient.

I'd guess that for a large-scale project the recommendation to use -u would be unrealistic. We are talking about projects where debugging information in a single section can easily go beyond the 4GiB limit; it is impossible for the developer to adjust the command line manually.

By the way, from a semantic point of view, I don't think it matters if the DWARF is in a different order to the data it represents - I'm just concerned about the maintenance and performance burden of having to parse the DWARF to achieve this reordering.

There is no need to parse the debug info sections. Reading only the first 4 bytes of .debug_info is enough to assess the format (there might be input files with format intermixing, but we can ignore them in the sack of simplicity). And we do not need any automatic sorting if the size of an output section is less than 4GiB.

Fri, Nov 6, 11:10 AM · debug-info, Restricted Project

Thu, Nov 5

ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Thu, Nov 5, 5:21 PM · Restricted Project
ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Thu, Nov 5, 11:44 AM · Restricted Project
ayermolo added a comment to D87011: [DebugInfo] Add the -dwarf64 switch to llc and other internal tools (4/19)..

@ikudrin Can you elaborate on LLD changes. I recently started to look in to it. Reason I am interested in this, internally we are a looking in to using DWARF64, so I have bandwidth, and incentive, to help with it implementation and adoption.

Thu, Nov 5, 10:46 AM · debug-info, Restricted Project

Wed, Nov 4

ayermolo added a comment to D87011: [DebugInfo] Add the -dwarf64 switch to llc and other internal tools (4/19)..

@ikudrin What else is left on clang side? I added a diff for passing a flag from clang to be, need to see what's up with failures, anything else that needs to be done?

Wed, Nov 4, 10:16 AM · debug-info, Restricted Project

Mon, Nov 2

ayermolo updated the diff for D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Mon, Nov 2, 9:57 AM · Restricted Project

Fri, Oct 30

ayermolo requested review of D90507: [Driver] Add DWARF64 flag: -gdwarf64.
Fri, Oct 30, 3:26 PM · Restricted Project

Wed, Oct 28

ayermolo added a comment to D87011: [DebugInfo] Add the -dwarf64 switch to llc and other internal tools (4/19)..

Awesome, thanks.
I was trying to pass in -dwarf64 through our build system, but was still seeing 32 bit relocations. Will dig further on my end.
Thanks for working on this.

Wed, Oct 28, 10:17 AM · debug-info, Restricted Project

Oct 27 2020

ayermolo added a comment to D87011: [DebugInfo] Add the -dwarf64 switch to llc and other internal tools (4/19)..

@ikudrin To clarify this will emit R_X86_64_64 bit relocations for .debug_info on 64 bit platform, correct?

Oct 27 2020, 6:04 PM · debug-info, Restricted Project

Sep 30 2020

ayermolo requested review of D88620: Revert SVML support for sqrt.
Sep 30 2020, 3:20 PM · Restricted Project

Sep 23 2020

ayermolo added inline comments to D74169: [WIP][LLD][ELF][DebugInfo] Remove obsolete debug info..
Sep 23 2020, 2:58 PM · debug-info, lld, Restricted Project
ayermolo added inline comments to D87169: SVML support for log10, sqrt.
Sep 23 2020, 2:38 PM · Restricted Project

Sep 22 2020

Herald added a reviewer for D46628: [ELF] Add --strip-debug-non-line option: jdoerfert.
Sep 22 2020, 5:06 PM · Restricted Project

Sep 15 2020

ayermolo added a comment to D87169: SVML support for log10, sqrt.

Thank you @craig.topper @wenlei

Sep 15 2020, 5:45 PM · Restricted Project
ayermolo added a comment to D87169: SVML support for log10, sqrt.

@craig.topper Any more questions/concerns? Can you approve?

Sep 15 2020, 4:34 PM · Restricted Project
ayermolo added a comment to D74169: [WIP][LLD][ELF][DebugInfo] Remove obsolete debug info..

@avl Would it be possible to rebase this on latest, or is this diff abandoned?

Sep 15 2020, 4:31 PM · debug-info, lld, Restricted Project

Sep 8 2020

ayermolo added a comment to D87169: SVML support for log10, sqrt.

We are linking against Intel Composer XE in to which svml libraries were added. I do believe they are from icc.

Sep 8 2020, 5:56 PM · Restricted Project

Sep 4 2020

ayermolo requested review of D87169: SVML support for log10, sqrt.
Sep 4 2020, 2:56 PM · Restricted Project

Sep 3 2020

ayermolo added inline comments to D53035: [LV] Legalize SVML call instructions during vector code generation.
Sep 3 2020, 6:37 PM · Restricted Project
ayermolo added a comment to D86730: SVML support for log2.

@wenlei Thanks!

Sep 3 2020, 12:03 PM · Restricted Project

Sep 2 2020

ayermolo added a comment to D86730: SVML support for log2.

Hi, can someone take a look at this please?

Sep 2 2020, 11:45 AM · Restricted Project

Aug 31 2020

ayermolo updated the diff for D86730: SVML support for log2.
Aug 31 2020, 4:03 PM · Restricted Project

Aug 27 2020

ayermolo updated the diff for D86730: SVML support for log2.
Aug 27 2020, 12:33 PM · Restricted Project
ayermolo added reviewers for D86730: SVML support for log2: wenlei, hoyFB, mmasten, mzolotukhin, spatel.
Aug 27 2020, 11:23 AM · Restricted Project
ayermolo requested review of D86730: SVML support for log2.
Aug 27 2020, 11:22 AM · Restricted Project

Aug 25 2020

Herald added a reviewer for D53035: [LV] Legalize SVML call instructions during vector code generation: jdoerfert.

@karthiksenthil are there any plans to resurrect this diff, and rebase on latest?

Aug 25 2020, 6:04 PM · Restricted Project