Re: [lldb-dev] [Release-testers] [7.0.0 Release] The final tag is in

2018-09-18 Thread Dimitry Andric via lldb-dev 
On 17 Sep 2018, at 13:41, Hans Wennborg via Release-testers 
 wrote:
> 
> The final version of 7.0.0 has been tagged from the branch at r342370.
> It is identical to rc3 modulo release notes and docs changes.

There weren't any code changes relative to rc3, so nothing changed in the test 
results either.  I have uploaded:

SHA256 (clang+llvm-7.0.0-amd64-unknown-freebsd11.tar.xz) = 
95ceb933ccf76e3ddaa536f41ab82c442bbac07cdea6f9fbf6e3b13cc1711255
SHA256 (clang+llvm-7.0.0-i386-unknown-freebsd11.tar.xz) = 
35460d34a8b3d856e0d7c0b2b20d31f0d1ec05908c830a81f586721e8f8fb04f

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] The final tag is in

2018-09-18 Thread Sylvestre Ledru via lldb-dev 
Le 17/09/2018 à 13:41, Hans Wennborg via Release-testers a écrit :
> Dear testers,
> 
> The final version of 7.0.0 has been tagged from the branch at r342370.
> It is identical to rc3 modulo release notes and docs changes.
> 
> Please build the final binaries and upload to the sftp.
> 
> For those following along: this means 7.0.0 is done, but it will take
> a few days to get all the tarballs ready and published on the web
> page. I will send the announcement once everything is ready.
> 
> Thanks again everyone for your work!
Looks great on Debian:
https://buildd.debian.org/status/package.php?p=llvm-toolchain-7

Just a problem on armel to build libc++ but this isn't a new regression
https://buildd.debian.org/status/package.php?p=libc%2B%2B&suite=sid

S
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO objects

2018-09-18 Thread via lldb-dev 
Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
DW_AT_ranges or is that expected?

Compile units should never be nested. That's invalid DWARF.  A unit is the root 
of the DIE tree described by each unit header.
Whatever is producing one unit contained inside another is doing something 
wrong.
--paulr

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Stefan 
Gränitz via lldb-dev
Sent: Friday, September 14, 2018 11:57 AM
To: LLDB Dev
Subject: Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO 
objects

I made some progress on this and next to many small issues, I found that 
DWARFDebugAranges::FindAddress() returns 0 as the CU offset for my file 
addresses and wonder if this is expected?

DWARFDebugAranges::FindAddress() is supposed to read from .debug_aranges 
section or DW_AT_ranges attributes right? When dumping with llvm-dwarfdump, it 
looks like regular objects have exactly one DW_TAG_compile_unit and it has a 
DW_AT_ranges attribute. Same for the top-level DW_TAG_compile_unit in LTO 
objects, but all further DW_TAG_compile_unit tags have no DW_AT_ranges 
attribute here. The comment in DWARFUnit::BuildAddressRangeTable() states that 
Clang “emits DW_AT_ranges for DW_TAG_compile_units”.

Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
DW_AT_ranges or is that expected?
It looks like FindAddress() would return the offset correctly if it was there 
and the fix may get simpler.

Top-level:
0x000b: DW_TAG_compile_unit
...
DW_AT_low_pc.  (0x)
DW_AT_ranges.  (0x0040
   [0x, 0x07de)
   [0x07f0, 0x33cd))

Nested:
0x000130b3: DW_TAG_compile_unit
...
DW_AT_low_pc   (0x3f50)
DW_AT_high_pc. (0xdd0f)



As far as I can tell, we need the actual number of CUs only after we discovered 
plugins.

Split that off into HasCompileUnits() and GetNumCompileUnits(). It works well 
so far. Also managed to extract the single CUs with correct offsets in the LTO 
object file once GetNumCompileUnits() calls InitOSO(). I kept the logic for 
associating the CUs with line ranges in the Symtab, so 
first/last_symbol_id/index are the same for all those CUs. Maybe the code needs 
a few more adjustments to support this, but so far I don’t see showstoppers.

Short recap for what works after the simple changes:
* We iterate over the actual CUs in 
BreakpointResolverFileLine::SearchCallback().
* For the matching CU, we get the actual list of support files and find the 
correct file_idx and line_entry in CompileUnit::ResolveSymbolContext().
* We correctly link the OSO line table for this CU (with some overhead due to 
overlapping symbol ranges, but IIUC it’s fine as we only pick the ones for the 
CU).


IF you do make a patch, please remove any functions in SymbolFileDWARFDebugMap 
that are dead code. SymbolFileDWARFDebugMap::GetModuleByOSOIndex() seems to be 
dead. If that is dead thenvSymbolFileDWARFDebugMap::GetObjectFileByOSOIndex() 
seems to be dead also.

Yes both functions are dead and yes sure, I can include that in my patch. 
Another one is SymbolFileDWARFDebugMap::PrivateFindGlobalVariables(), which is 
one of the clients for symbol slices/ranges. The remaining ones are 
SymbolFileDWARFDebugMap::SymbolContainsSymbolWithID/Index() and 
SymbolFileDWARFDebugMap::CompileUnitInfo::GetFileRangeMap(), which are all 
alive.



On 11. Sep 2018, at 20:13, Stefan Gränitz via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

Thanks for your replies!


Right now we assume that each .o file has only on CU so we don't need to open 
all .o files in SymbolFileDWARFDebugMap::CalculateAbilities() which is 
something that gets run when we are trying to figure out which SymbolFile 
plug-in to load. [...] The problem used to be that even if we had a dSYM file, 
the loop that selected the symbol file plug-in would give each and every symbol 
file plugin a chance ...

Ok makes total sense, kind of historical reason.

But that being said, in the past I re-ordered how the SymbolFile plug-ins were 
initialized to always put SymbolFileDWARF first and if it finds DWARF debug 
info or a dSYM file and has all the abilities then we stop looking for symbol 
file plug-ins that can load the current file. [...] So as soon as a SymbolFile 
plug-in can do everything we now stop.

Good to know!

Note that counting the number of compile units can be done extremely cheaply 
(of course, except the cost of opening the file). Each unit as a header that 
contain its length (which gives you the next unit). I’m not sure we have a 
primitive that does this without parsing the DWARF, but it should be easy to 
add.

Right, so we only need to parse the CU headers. That should be fast.
Opening each candidate .o file for the relatively rare case of having multiple 
CUs still sounds expensive, assuming that “thousands of .o files” may actually 
happen.

CalculateAbilities()

Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO objects

2018-09-18 Thread Stefan Gränitz via lldb-dev 
Hi Paul, thanks for the clarification. Yes, that was my fault. The LTO object 
DWARF has multiple top-level compile unit tags and only the first one has a 
DW_AT_ranges attribute.

One more thought here: In DWARFDebugInfo::GetCompileUnitAranges() LLDB 
currently tries to read .debug_aranges and if it can’t, it falls back to 
reading DW_AT_ranges from the compile unit tags. Would you have  objections 
from constructing that range from DW_AT_low_pc and DW_AT_high_pc here, if they 
exist? IIUC code for a single compile unit is not guaranteed to be compact, but 
in practice it usually is right?

Thanks
Stefan

> On 18. Sep 2018, at 15:01, paul.robin...@sony.com wrote:
> 
> Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
> DW_AT_ranges or is that expected?
>  
> Compile units should never be nested. That's invalid DWARF.  A unit is the 
> root of the DIE tree described by each unit header. <>
> Whatever is producing one unit contained inside another is doing something 
> wrong.
> --paulr
>  
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Stefan 
> Gränitz via lldb-dev
> Sent: Friday, September 14, 2018 11:57 AM
> To: LLDB Dev
> Subject: Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO 
> objects
>  
> I made some progress on this and next to many small issues, I found that 
> DWARFDebugAranges::FindAddress() returns 0 as the CU offset for my file 
> addresses and wonder if this is expected?
>  
> DWARFDebugAranges::FindAddress() is supposed to read from .debug_aranges 
> section or DW_AT_ranges attributes right? When dumping with llvm-dwarfdump, 
> it looks like regular objects have exactly one DW_TAG_compile_unit and it has 
> a DW_AT_ranges attribute. Same for the top-level DW_TAG_compile_unit in LTO 
> objects, but all further DW_TAG_compile_unit tags have no DW_AT_ranges 
> attribute here. The comment in DWARFUnit::BuildAddressRangeTable() states 
> that Clang “emits DW_AT_ranges for DW_TAG_compile_units”.
>  
> Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
> DW_AT_ranges or is that expected?
> It looks like FindAddress() would return the offset correctly if it was there 
> and the fix may get simpler.
>  
> Top-level:
> 0x000b: DW_TAG_compile_unit
> ...
> DW_AT_low_pc.  (0x)
> DW_AT_ranges.  (0x0040
>[0x, 0x07de)
>[0x07f0, 0x33cd))
>  
> Nested:
> 0x000130b3: DW_TAG_compile_unit
> ...
> DW_AT_low_pc   (0x3f50)
> DW_AT_high_pc. (0xdd0f)
>  
> 
> 
> As far as I can tell, we need the actual number of CUs only after we 
> discovered plugins.
>  
> Split that off into HasCompileUnits() and GetNumCompileUnits(). It works well 
> so far. Also managed to extract the single CUs with correct offsets in the 
> LTO object file once GetNumCompileUnits() calls InitOSO(). I kept the logic 
> for associating the CUs with line ranges in the Symtab, so 
> first/last_symbol_id/index are the same for all those CUs. Maybe the code 
> needs a few more adjustments to support this, but so far I don’t see 
> showstoppers.
>  
> Short recap for what works after the simple changes:
> * We iterate over the actual CUs in 
> BreakpointResolverFileLine::SearchCallback().
> * For the matching CU, we get the actual list of support files and find the 
> correct file_idx and line_entry in CompileUnit::ResolveSymbolContext().
> * We correctly link the OSO line table for this CU (with some overhead due to 
> overlapping symbol ranges, but IIUC it’s fine as we only pick the ones for 
> the CU).
>  
>  
> IF you do make a patch, please remove any functions in 
> SymbolFileDWARFDebugMap that are dead code. 
> SymbolFileDWARFDebugMap::GetModuleByOSOIndex() seems to be dead. If that is 
> dead thenvSymbolFileDWARFDebugMap::GetObjectFileByOSOIndex() seems to be dead 
> also.
>  
> Yes both functions are dead and yes sure, I can include that in my patch. 
> Another one is SymbolFileDWARFDebugMap::PrivateFindGlobalVariables(), which 
> is one of the clients for symbol slices/ranges. The remaining ones are 
> SymbolFileDWARFDebugMap::SymbolContainsSymbolWithID/Index() and 
> SymbolFileDWARFDebugMap::CompileUnitInfo::GetFileRangeMap(), which are all 
> alive.
>  
> 
> 
> On 11. Sep 2018, at 20:13, Stefan Gränitz via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
>  
> Thanks for your replies!
> 
> 
> Right now we assume that each .o file has only on CU so we don't need to open 
> all .o files in SymbolFileDWARFDebugMap::CalculateAbilities() which is 
> something that gets run when we are trying to figure out which SymbolFile 
> plug-in to load. [...] The problem used to be that even if we had a dSYM 
> file, the loop that selected the symbol file plug-in would give each and 
> every symbol file plugin a chance ...
>  
> Ok makes total sense, kind of historical reason.
>  
> But that being said, in the past I re-ordered

Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO objects

2018-09-18 Thread via lldb-dev 
A contiguous range certainly can be described with a low_pc/high_pc pair. if 
LLDB is looking for DW_AT_ranges but not low/high pairs, it risks missing 
information about a CU.  I'm not an LLDB dev but I can't imagine anyone 
thinking that it would be a problem to fix that.
--paulr

From: sgraen...@apple.com [mailto:sgraen...@apple.com]
Sent: Tuesday, September 18, 2018 1:35 PM
To: Robinson, Paul
Cc: LLDB Dev
Subject: Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO 
objects

Hi Paul, thanks for the clarification. Yes, that was my fault. The LTO object 
DWARF has multiple top-level compile unit tags and only the first one has a 
DW_AT_ranges attribute.

One more thought here: In DWARFDebugInfo::GetCompileUnitAranges() LLDB 
currently tries to read .debug_aranges and if it can’t, it falls back to 
reading DW_AT_ranges from the compile unit tags. Would you have  objections 
from constructing that range from DW_AT_low_pc and DW_AT_high_pc here, if they 
exist? IIUC code for a single compile unit is not guaranteed to be compact, but 
in practice it usually is right?

Thanks
Stefan


On 18. Sep 2018, at 15:01, 
paul.robin...@sony.com wrote:

Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
DW_AT_ranges or is that expected?

Compile units should never be nested. That's invalid DWARF.  A unit is the root 
of the DIE tree described by each unit header.
Whatever is producing one unit contained inside another is doing something 
wrong.
--paulr

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Stefan 
Gränitz via lldb-dev
Sent: Friday, September 14, 2018 11:57 AM
To: LLDB Dev
Subject: Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO 
objects

I made some progress on this and next to many small issues, I found that 
DWARFDebugAranges::FindAddress() returns 0 as the CU offset for my file 
addresses and wonder if this is expected?

DWARFDebugAranges::FindAddress() is supposed to read from .debug_aranges 
section or DW_AT_ranges attributes right? When dumping with llvm-dwarfdump, it 
looks like regular objects have exactly one DW_TAG_compile_unit and it has a 
DW_AT_ranges attribute. Same for the top-level DW_TAG_compile_unit in LTO 
objects, but all further DW_TAG_compile_unit tags have no DW_AT_ranges 
attribute here. The comment in DWARFUnit::BuildAddressRangeTable() states that 
Clang “emits DW_AT_ranges for DW_TAG_compile_units”.

Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
DW_AT_ranges or is that expected?
It looks like FindAddress() would return the offset correctly if it was there 
and the fix may get simpler.

Top-level:
0x000b: DW_TAG_compile_unit
...
DW_AT_low_pc.  (0x)
DW_AT_ranges.  (0x0040
   [0x, 0x07de)
   [0x07f0, 0x33cd))

Nested:
0x000130b3: DW_TAG_compile_unit
...
DW_AT_low_pc   (0x3f50)
DW_AT_high_pc. (0xdd0f)




As far as I can tell, we need the actual number of CUs only after we discovered 
plugins.

Split that off into HasCompileUnits() and GetNumCompileUnits(). It works well 
so far. Also managed to extract the single CUs with correct offsets in the LTO 
object file once GetNumCompileUnits() calls InitOSO(). I kept the logic for 
associating the CUs with line ranges in the Symtab, so 
first/last_symbol_id/index are the same for all those CUs. Maybe the code needs 
a few more adjustments to support this, but so far I don’t see showstoppers.

Short recap for what works after the simple changes:
* We iterate over the actual CUs in 
BreakpointResolverFileLine::SearchCallback().
* For the matching CU, we get the actual list of support files and find the 
correct file_idx and line_entry in CompileUnit::ResolveSymbolContext().
* We correctly link the OSO line table for this CU (with some overhead due to 
overlapping symbol ranges, but IIUC it’s fine as we only pick the ones for the 
CU).


IF you do make a patch, please remove any functions in SymbolFileDWARFDebugMap 
that are dead code. SymbolFileDWARFDebugMap::GetModuleByOSOIndex() seems to be 
dead. If that is dead thenvSymbolFileDWARFDebugMap::GetObjectFileByOSOIndex() 
seems to be dead also.

Yes both functions are dead and yes sure, I can include that in my patch. 
Another one is SymbolFileDWARFDebugMap::PrivateFindGlobalVariables(), which is 
one of the clients for symbol slices/ranges. The remaining ones are 
SymbolFileDWARFDebugMap::SymbolContainsSymbolWithID/Index() and 
SymbolFileDWARFDebugMap::CompileUnitInfo::GetFileRangeMap(), which are all 
alive.




On 11. Sep 2018, at 20:13, Stefan Gränitz via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

Thanks for your replies!



Right now we assume that each .o file has only on CU so we don't need to open 
all .o files in SymbolFileDWARFDebugMap::CalculateAbilities() which is 
something that gets run when we are trying to figur

Re: [lldb-dev] [Release-testers] [7.0.0 Release] The final tag is in

2018-09-18 Thread Brian Cain via lldb-dev 
Uploaded SLES binaries:

07d289c409e359f1d453d3b3ff66dfa36889d28b
clang+llvm-7.0.0-x86_64-linux-sles11.3.tar.xz
2c07e6f7ebcb71852ad3fe8d69dc7ca3ee580a59
clang+llvm-7.0.0-x86_64-linux-sles12.3.tar.xz


On Mon, Sep 17, 2018 at 6:42 AM Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> The final version of 7.0.0 has been tagged from the branch at r342370.
> It is identical to rc3 modulo release notes and docs changes.
>
> Please build the final binaries and upload to the sftp.
>
> For those following along: this means 7.0.0 is done, but it will take
> a few days to get all the tarballs ready and published on the web
> page. I will send the announcement once everything is ready.
>
> Thanks again everyone for your work!
>
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


-- 
-Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev