Re: [lldb-dev] LLDB Evolution: Next Phase

2016-08-22 Thread Pavel Labath via lldb-dev 
On 19 August 2016 at 22:10, Kate Stone via lldb-dev
 wrote:
> Following up from yesterday, everything now builds and runs cleanly with the
> configuration described below on macOS.  I did have to make one set of minor
> changes to preserve #include ordering, but that’s already committed to trunk
> so there are no true blockers at this point.  To keep pushing forward I’d
> like to propose the following final schedule for comment:
>
> Today-Sept 4th Any final changes to prevent automatic formatting (see
> existing uses of // clang-format off and // clang-format on in source for
> reference.
> Sept 5th Trunk closes for commits while reformatting takes place and is
> validated before re-opening trunk.
>
> Following the reformatting trying to merge the resulting diff will be a
> nightmare for anyone with their own long-lived branch or fork of the
> project.  We’ll include a commit message describing the situation, but the
> sanest move is almost certainly to merge all diffs up to the formatting
> exercise and then simply format your own branch independently in lieu of
> actually attempting the merge.  We will ensure that nothing takes place in
> that commit aside from the automated formatting.
>
> We’ll be following the same strategy with the swift-lldb repository on
> GitHub.
>
> Any concerns?
>
> Kate Stone k8st...@apple.com
>  Xcode Low Level Tools

The plan sounds good to me. I have a question about the "validation"
part of the process.

Who will be doing that and what will be the exit criteria?

From our side, we can consider the process a success if the following
three buildbots remain green after the reformat:

(builds linux and android),

(build and test linux) and
 (builds
windows). Note that the last buildbot also runs remote android tests,
which are still somewhat flaky, but the build step there is pretty
important as it using MSVC.

If anything goes wrong there, I will be available on Tuesday morning
(GMT) to diagnose and fix problems.

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

[lldb-dev] Linux ELF header e_ident[EI_OSABI] value

2016-08-22 Thread Howard Hellyer via lldb-dev 
I've been trying to understand why some Linux core files fail to load in 
lldb.

The problem seems to be that in the ELF header Linux uses the 
ELFOSABI_NONE (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either 
change the e_ident[EI_OSABI] byte to 0x3 in the header or the code in 
ArchSpec.cpp to treat ELFOSABI_NONE as Linux then LLDB will open these 
core files perfectly. The Linux core dumps that are being opened 
successfully seem to be doing so because lldb is using extra optional 
information in the notes section. Either because it contains notes “owned” 
by Linux or because of the file names contained in the FILE note type. A 
lot of core dumps (it appears to be those created by the kernel following 
a crash rather than gcore) don’t contain the “LINUX” notes and the file 
paths in the FILE note can vary a lot by Linux distribution. (For example 
Ubuntu cores work but Redhat cores I've tried don't as the libraries are 
in different locations.)

Linux doesn't seem to use the ELFOSABIT_LINUX value (0x3) but sticks to 
the ELFOSABI_NONE (0x0) value. This apppears to be true for both 
executables and core dumps, LLVM was changed to follow this convention 
(see: 
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301607.html 
) but lldb still looks for ELFOSABI_LINUX in ELF headers even though 
executables and core files seem to contain ELFOSABI_NONE in practise. If I 
compile code with clang the resulting executable uses ELFOSABI_NONE in the 
e_ident[EI_OSABI] byte. (If I change the byte manually Linux doesn't 
appear to care. I think it's probably ignoring the byte.)

I'd like to submit a patch to change lldb to treat ELF files with 
ELFOSABI_NONE set as Linux as a) it would allow lldb to open Linux cores 
reliably and b) it would match how clang treats e_ident[EI_OSABI]. The 
code to detect whether lldb is opening a Linux core has changed a lot 
recently and I don't know the history or if any other ELF platforms leave 
this byte set to 0x0 in which case this would be confusing, though as this 
value is currently unused it seems safe.

Does anyone know of any reason not to change this? If not I'll submit a 
patch for review.

Howard Hellyer
IBM Runtime Technologies, IBM Systems
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

2016-08-22 Thread Greg Clayton via lldb-dev 

> On Aug 22, 2016, at 6:00 AM, Howard Hellyer via lldb-dev 
>  wrote:
> 
> I've been trying to understand why some Linux core files fail to load in 
> lldb. 
> 
> The problem seems to be that in the ELF header Linux uses the ELFOSABI_NONE 
> (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either change the 
> e_ident[EI_OSABI] byte to 0x3 in the header or the code in ArchSpec.cpp to 
> treat ELFOSABI_NONE as Linux then LLDB will open these core files perfectly. 
> The Linux core dumps that are being opened successfully seem to be doing so 
> because lldb is using extra optional information in the notes section. Either 
> because it contains notes “owned” by Linux or because of the file names 
> contained in the FILE note type. A lot of core dumps (it appears to be those 
> created by the kernel following a crash rather than gcore) don’t contain the 
> “LINUX” notes and the file paths in the FILE note can vary a lot by Linux 
> distribution. (For example Ubuntu cores work but Redhat cores I've tried 
> don't as the libraries are in different locations.) 
> 
> Linux doesn't seem to use the ELFOSABIT_LINUX value (0x3) but sticks to the 
> ELFOSABI_NONE (0x0) value. This apppears to be true for both executables and 
> core dumps, LLVM was changed to follow this convention (see: 
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301607.html 
> ) but lldb still looks for ELFOSABI_LINUX in ELF headers even though 
> executables and core files seem to contain ELFOSABI_NONE in practise. If I 
> compile code with clang the resulting executable uses ELFOSABI_NONE in the 
> e_ident[EI_OSABI] byte. (If I change the byte manually Linux doesn't appear 
> to care. I think it's probably ignoring the byte.) 
> 
> I'd like to submit a patch to change lldb to treat ELF files with 
> ELFOSABI_NONE set as Linux as a) it would allow lldb to open Linux cores 
> reliably and b) it would match how clang treats e_ident[EI_OSABI]. The code 
> to detect whether lldb is opening a Linux core has changed a lot recently and 
> I don't know the history or if any other ELF platforms leave this byte set to 
> 0x0 in which case this would be confusing, though as this value is currently 
> unused it seems safe. 
> 
> Does anyone know of any reason not to change this? If not I'll submit a patch 
> for review. 

I would change it so that the "os" doesn't get set to anything when it detects 
this in the core file. When an OS is not specified, the llvm::Triple will 
return OSUnknown as the enumeration value for the OS _and_ the llvm::StringRef 
value will return an empty string. This is known in LLDB term as a "unspecified 
unknown". This means the triple will be "x86_64-*-". An unspecified 
unknown is a wildcard. Any plugins that are trying to load a core file should 
watch for this and use it accordingly.

So the answer is not "treat ELF files with ELFOSABI_NONE set as Linux", but 
"treat ELF files with ELFOSABI_NONE set as *". Please submit a patch that 
implements this when you get the chance. Let me know if you have any questions.

Greg Clayton

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

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 2 has been tagged

2016-08-22 Thread Hans Wennborg via lldb-dev 
On Sat, Aug 20, 2016 at 2:45 PM, Sylvestre Ledru  wrote:
> Le 19/08/2016 à 03:51, Hans Wennborg via Release-testers a écrit :
>>
>> Dear testers,
>>
>> 3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
>>
>> This is a release candidate in the very real sense that if nothing new
>> comes up, this is be what the final release looks like. There are
>> currently no open release blockers, and no patches in my merge-queue.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> everything goes.
>>
>> From this point, the branch is only open for fixing critical problems
>> (bad enough to warrant another test cycle) and release notes.
>
> Seems to work great on Debian.
> https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.9&suite=experimental
> A bit surprised to see include fixer coming in the second rc but why not.

It was already being built, tested and in the release notes, but the
binary wasn't part of the 'install' target so we just fixed that part.

> However, still the same issue on armel:
> http://lists.llvm.org/pipermail/llvm-dev/2016-August/103457.html

:-( Not a 3.9 regression though.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] Release Candidate 2 source and binaries available

2016-08-22 Thread Hans Wennborg via lldb-dev 
We're getting close to the final release. I know the schedule on the
web page says 'final' should be tagged today, but I still think it
should be possible to get there this week.

Source and binaries for LLVM-3.9.0-rc2 are now available at
http://llvm.org/pre-releases/3.9.0/#rc2

Please try it out and let me know if you find any issues.

As we're running out of time, RC2 will be a short test cycle, so if
you're planning on testing it, please don't procrastinate it :-)

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

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

2016-08-22 Thread Ted Woodward via lldb-dev 
We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is historically 
ELFOSABI_SYSV, and used by a lot of things. So not all core files identified as 
ELFOSABI_NONE are Linux.  

Whe lldb loads a core file with a target binary, it will merge the 2 triples. 
If it can't identify the OS from the core file, it will use the OS from the 
target file. For example, I just loaded a Hexagon Linux core file, which lldb 
didn't identify as Linux, and a Hexagon Linux target, which lldb did identify 
as Linux. The final triple is correct - hexagon-*-linux:
(lldb) file u:\hexagon-linux\crash -c u:\hexagon-linux\core
Core file 'u:\hexagon-linux\core' (hexagon) was loaded.
(lldb) tar list
Current targets:
* target #0: u:\hexagon-linux\crash ( arch=hexagon-*-linux, 
platform=remote-linux, pid=13818, state=stopped )


ObjectFileELF::RefineModuleDetailsFromNote looks for a note with type NT_FILE, 
then looks in that for a path that starts with "/lib/x86_64-linux-gnu". If it 
finds that, it will set the core file's OS to Linux. Teaching that to speak the 
Linux dialect you're interested in is probably the right way to go.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
Clayton via lldb-dev
Sent: Monday, August 22, 2016 11:00 AM
To: Howard Hellyer 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value


> On Aug 22, 2016, at 6:00 AM, Howard Hellyer via lldb-dev 
>  wrote:
> 
> I've been trying to understand why some Linux core files fail to load in 
> lldb. 
> 
> The problem seems to be that in the ELF header Linux uses the ELFOSABI_NONE 
> (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either change the 
> e_ident[EI_OSABI] byte to 0x3 in the header or the code in ArchSpec.cpp to 
> treat ELFOSABI_NONE as Linux then LLDB will open these core files perfectly. 
> The Linux core dumps that are being opened successfully seem to be doing so 
> because lldb is using extra optional information in the notes section. Either 
> because it contains notes “owned” by Linux or because of the file names 
> contained in the FILE note type. A lot of core dumps (it appears to be those 
> created by the kernel following a crash rather than gcore) don’t contain the 
> “LINUX” notes and the file paths in the FILE note can vary a lot by Linux 
> distribution. (For example Ubuntu cores work but Redhat cores I've tried 
> don't as the libraries are in different locations.) 
> 
> Linux doesn't seem to use the ELFOSABIT_LINUX value (0x3) but sticks to the 
> ELFOSABI_NONE (0x0) value. This apppears to be true for both executables and 
> core dumps, LLVM was changed to follow this convention (see: 
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301607.html 
> ) but lldb still looks for ELFOSABI_LINUX in ELF headers even though 
> executables and core files seem to contain ELFOSABI_NONE in practise. If I 
> compile code with clang the resulting executable uses ELFOSABI_NONE in the 
> e_ident[EI_OSABI] byte. (If I change the byte manually Linux doesn't appear 
> to care. I think it's probably ignoring the byte.) 
> 
> I'd like to submit a patch to change lldb to treat ELF files with 
> ELFOSABI_NONE set as Linux as a) it would allow lldb to open Linux cores 
> reliably and b) it would match how clang treats e_ident[EI_OSABI]. The code 
> to detect whether lldb is opening a Linux core has changed a lot recently and 
> I don't know the history or if any other ELF platforms leave this byte set to 
> 0x0 in which case this would be confusing, though as this value is currently 
> unused it seems safe. 
> 
> Does anyone know of any reason not to change this? If not I'll submit a patch 
> for review. 

I would change it so that the "os" doesn't get set to anything when it detects 
this in the core file. When an OS is not specified, the llvm::Triple will 
return OSUnknown as the enumeration value for the OS _and_ the llvm::StringRef 
value will return an empty string. This is known in LLDB term as a "unspecified 
unknown". This means the triple will be "x86_64-*-". An unspecified 
unknown is a wildcard. Any plugins that are trying to load a core file should 
watch for this and use it accordingly.

So the answer is not "treat ELF files with ELFOSABI_NONE set as Linux", but 
"treat ELF files with ELFOSABI_NONE set as *". Please submit a patch that 
implements this when you get the chance. Let me know if you have any questions.

Greg Clayton

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

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

[lldb-dev] LLVM Social in Berlin, Germany. 25.08.2016

2016-08-22 Thread Alex Denisov via lldb-dev 
Hello everybody,

Just want to let you know that the first LLVM Social in Berlin will happen this 
Thursday, 19:00 CET.
The place is a nice co-working space/cafe called Betahaus: 
https://www.google.com/maps?f=q&hl=en&q=Prinzessinnenstrasse+19-20+10969,+,+Berlin,+de

Looking forward to meet you all.
--
AlexDenisov
Software Engineer, http://lowlevelbits.org



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

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 2 source and binaries available

2016-08-22 Thread Renato Golin via lldb-dev 
Hi Hans,

I did upload the aarch64 binary, didn't you find it? Maybe I uploaded the
wrong one?

Cheers,
Renato

On 22 Aug 2016 7:55 p.m., "Hans Wennborg via Release-testers" <
release-test...@lists.llvm.org> wrote:

> We're getting close to the final release. I know the schedule on the
> web page says 'final' should be tagged today, but I still think it
> should be possible to get there this week.
>
> Source and binaries for LLVM-3.9.0-rc2 are now available at
> http://llvm.org/pre-releases/3.9.0/#rc2
>
> Please try it out and let me know if you find any issues.
>
> As we're running out of time, RC2 will be a short test cycle, so if
> you're planning on testing it, please don't procrastinate it :-)
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 2 source and binaries available

2016-08-22 Thread Hans Wennborg via lldb-dev 
I replied on the "has been tagged" thread; I couldn't find the binary
on the sftp. Maybe you uploaded the wrong version, or in some other
folder?

On Mon, Aug 22, 2016 at 4:01 PM, Renato Golin  wrote:
> Hi Hans,
>
> I did upload the aarch64 binary, didn't you find it? Maybe I uploaded the
> wrong one?
>
> Cheers,
> Renato
>
>
> On 22 Aug 2016 7:55 p.m., "Hans Wennborg via Release-testers"
>  wrote:
>>
>> We're getting close to the final release. I know the schedule on the
>> web page says 'final' should be tagged today, but I still think it
>> should be possible to get there this week.
>>
>> Source and binaries for LLVM-3.9.0-rc2 are now available at
>> http://llvm.org/pre-releases/3.9.0/#rc2
>>
>> Please try it out and let me know if you find any issues.
>>
>> As we're running out of time, RC2 will be a short test cycle, so if
>> you're planning on testing it, please don't procrastinate it :-)
>>
>> Thanks,
>> Hans
>> ___
>> Release-testers mailing list
>> release-test...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev