[lldb-dev] [Bug 46045] New: inconsistent behaviors at -O1
https://bugs.llvm.org/show_bug.cgi?id=46045
Bug ID: 46045
Summary: inconsistent behaviors at -O1
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -O1 -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 22
Breakpoint 1: where = a.out`foo + 37 at small.c:22:3, address =
0x00401135
(lldb) r
Process 367418 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 367418 exited with status = 0 (0x)
(lldb)
/*
As showed above, when setting breakpoint at Line 22, lldb wrongly exit
directly.
Line 22 is actually executed in step-i as follow:
*/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 1 at small.c:26:3, address =
0x00401151
(lldb) r
Process 367312 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 367312 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401151 a.out`main at small.c:26:3
23 }
24
25 int main() {
-> 26 foo();
27 return 0;
28 }
(lldb) si -c 9
Process 367312 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x0040113f a.out`foo at small.c:22:3
19 if (pn->p==(void *)ph)
20 ph->f = &nd;
21
-> 22 return 0;
23 }
24
25 int main() {
(lldb)
--- Comment #1 from Yibiao Yang (杨已彪) ---
*** Bug 46046 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 46046] New: inconsistent behaviors at -O1
https://bugs.llvm.org/show_bug.cgi?id=46046
Bug ID: 46046
Summary: inconsistent behaviors at -O1
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: RESOLVED
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
Status: RESOLVED
Resolution: DUPLICATE
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -O1 -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 22
Breakpoint 1: where = a.out`foo + 37 at small.c:22:3, address =
0x00401135
(lldb) r
Process 367418 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 367418 exited with status = 0 (0x)
(lldb)
/*
As showed above, when setting breakpoint at Line 22, lldb wrongly exit
directly.
Line 22 is actually executed in step-i as follow:
*/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 1 at small.c:26:3, address =
0x00401151
(lldb) r
Process 367312 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 367312 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401151 a.out`main at small.c:26:3
23 }
24
25 int main() {
-> 26 foo();
27 return 0;
28 }
(lldb) si -c 9
Process 367312 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x0040113f a.out`foo at small.c:22:3
19 if (pn->p==(void *)ph)
20 ph->f = &nd;
21
-> 22 return 0;
23 }
24
25 int main() {
(lldb)
$ cat small.c
struct sn {
struct sn *n;
struct sn *p;
} nd;
struct sh {
struct sn *f;
} hs[2];
struct sh *h=&hs[0];
int foo() {
nd.p = (void*)h;
h->f = &nd;
struct sn *pn=h->f;
struct sh *ph=h;
if (pn->p==(void *)ph)
ph->f = &nd;
return 0;
}
int main() {
foo();
return 0;
}
--- Comment #1 from Yibiao Yang (杨已彪) ---
*** This bug has been marked as a duplicate of bug 46045 ***
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] 10.0.1-rc1 release has been tagged
On Tue, 2020-05-19 at 18:22 -0700, Tom Stellard via Release-testers wrote: > Hi, > > I have just tagged the 10.0.1-rc1 release. Testers can begin testing and > uploading > binaries. > > If you still want to get a fix into the 10.0.1 release, you still have about > a month > to get your fix in. To request a patch be backported to the release/10.x > branch, > file a bug and mark it as a blocker of the release-10.0.1 meta bug. > Ok, it turns out my issues were due to py3.7+. I've requested backporting one lit patch and with it, there are no new regressions. However, it made me notice that some clangd unittest are failing to execute with duplicate command-line option errors but the errors are ignored by lit. It happens when clang is linked to dylib, and it is non-trivial to fix and I'm not sure if I'll be able to fix it myself. Any and all help appreciated. I've tried to see if it is fixed in master but I can't seem to manage to find a recent clang revision that wouldn't segfault all the way. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] RFC: Release process changes
On Thu, May 21, 2020 at 8:59 PM Tom Stellard via Openmp-dev wrote: > > Hi, > > I would like to propose a few changes to the LLVM release process. The > current process is documented here: > https://llvm.org/docs/HowToReleaseLLVM.html > > There are two parts to this proposal. The first is a list of clarifications, > which are things we are currently doing that aren't documented. The second > is a list of changes which would actually modify how releases are currently > managed. > > > > *** Proposed Clarifications *** > > > > ** Release manager is allowed to commit changes to the release branch without > code owner approval. However, the release manager is encouraged to > consult > with code owners or patch reviewers for non-trivial changes. > > It's not practical to get code owner approval every time. Either because > there > is no code owner or because the number of backports is too high (e.g. pre-rc1 > / pre-rc2). > This proposed clarification matches how releases are currently managed. +1 Maybe even stronger than "is allowed to commit", I think we should really think about it as the release manager owning the branch, and has full authority over what goes into it or not. Consulting code owners often makes sense of course, but for many patches, consulting the code owner (when there is one) is an unnecessary slowdown. > ** There is no official release criteria. > > We have time-based releases and when the release is 'ready' has been > up to the discretion of the release manager. Changing the release > criteria is out of the scope of this proposal, but I do think it would > be good to have a discussion about this as a community, so I'm going to > start a separate thread to discuss this. > > > > *** Proposed Changes *** > > > > ** Create a time-based bug-fix release schedule. After each major release, > make >a new bug-fix release every 2 weeks for 12 weeks (6 releases total). > > ** Eliminate release candidates for bug-fix releases. > > The current unofficial bug-fix release schedule is: > > X.Y.1-rc1 (6 weeks after major release) > X.Y.1-rc2 (10 weeks after major release) > X.Y.1-final (12 weeks after major release) > > I think this change will improve the overall test coverage of the release > branch. > I don't think the branch itself or even the release candidates get the same > level of testing as the final releases. If we are consistently snapshotting > the release branch and putting out releases, I think this will make it easier > and thus more likely that users will test out the release branch code. > > Additionally, with more frequent bug-fix release it removes the need to have > release candidate releases. Every bug-fix release (up until the last one) > would serve the same purpose as our current release candidates in that they > are intended to give users an easier way to test the code before the final > release. My first thought is that doing all these releases sounds like a lot of work. Would you be doing all of them, or would there be some other arrangement? I suppose if we release this often, and also skip the RCs, we might become more efficient at it :-) Secondly, is having this many releases useful for downstream? One concern might be that downstream consumers just wait for the .6 one, and then there's no benefit and also no extra testing of the branch. Is it mainly increasing test coverage of the branch that's the motivation, or is it the demand for more bug-fix releases? Not having at least one release candidate sounds a bit scary to be. Without them we could get into a situation where everything works fine on the release manager's machines, but is completely broken on other platforms, and no way to fix until the next dot release. Maybe that kind of breakage is less likely after the major release, but it still seems it could make these dot releases less stable? > ** Create clear rules for what kind of backports are accepted during each >release phase. > > * Before RC1:Patches should be limited to bug fixes, important optimization > improvements, or completion of features that were started before the branch > was created. As with all phases, release managers and code owners can > reject > patches that are deemed too invasive. > > * Before RC2: Patches should be limited to bug fixes or backend specific > improvements that are determined to be very safe. > > * Before RC3/Final: Major Release* Patches should be limited to critical > bugs or regressions. > > * Bug fix releases: Patches should be limited to bug fixes or very safe > and critical performance improvements. Patches must maintain both API and > ABI compatibility with the previous major release. > > * Final bug fix release: Patches should be limited to critical bug fixes only. These sound good to me. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] RFC: Release qualification criteria
On Thu, May 21, 2020 at 8:59 PM Tom Stellard via Openmp-dev wrote: > > Hi, > > I'm splitting this discussion off of my RFC for release process > changes. > > We currently have no official release qualification criteria. In > other words, we don't have any blocking tests that need to pass in > order to make a new release. > > We do time-based releases, which is not always compatible with having > quality-based criteria for tagging a final release. So, I think another > way to look at this issue is to talk about what kinds of CI testing we > have for trunk and if there are any additional kinds of > testing (e.g. compile-time performance) that we want to prioritize. > > So, for the purposes of this discussion, I see 2 main questions: > > 1. Should we define some set of blocking tests that need to pass before a > release >can happen? I suppose we could have a baseline about clang bootstrap + lit tests (what test-release.sh does essentially) passes on major platforms. But the really interesting question for me is really what kind of bugs we're considering as release blocking. It's the trade-off between shipping on (or not too much behind schedule) and delaying to investigate more issues that's tricky.. > > 2. What gaps do we currently have in our CI testing? The latest release made it clear we don't track compile time very well, or at least not well enough to catch the regressions in that release early enough. Also I think there's no 32-bit Windows buildbot anymore :/ ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
