Re: [Lldb-commits] [PATCH] D91734: [FastISel] Flush local value map on every instruction

[Robinson, Paul via lldb-commits]

> -Original Message-
> From: Jim Ingham 
> Sent: Thursday, December 3, 2020 5:51 PM
> To: David Blaikie
> ; David Blaikie
> via Phabricator 
> Cc: Robinson, Paul ; r...@google.com;
> echri...@gmail.com; sontuan.vu...@gmail.com; mcros...@codeaurora.org;
> nikola.te...@syrmia.com; lldb-commits ;
> liburd1...@outlook.com; stefan.graen...@gmail.com; ma...@braunis.de;
> nemanja.i@gmail.com; simon.dar...@gmail.com; Tozer, Stephen
> ; alokkumar.sha...@amd.com; s...@chromium.org;
> sourabhsingh.to...@amd.com; Jackson, Chris ;
> arpha...@gmail.com; j...@us.ibm.com; ...@gmail.com;
> horse10241...@gmail.com; pengfei.w...@intel.com; david.gr...@arm.com;
> higuox...@gmail.com; ikud...@accesssoftek.com; p8u8i7l5t1q9r8w3@ibm-
> systems-z.slack.com; Enciso, Carlos ; llvm-
> comm...@lists.llvm.org; Cazalet-Hyams, Orlando ;
> aso...@cisco.com; sani...@subpath.org; si...@atanasyan.com;
> jrt...@jrtc27.com; djordje.todoro...@syrmia.com; ch.besson...@gmail.com;
> quentin.colom...@gmail.com; akhu...@google.com; ahee...@gmail.com;
> avl.laps...@gmail.com; david.stenb...@ericsson.com;
> david.spick...@linaro.org; dougp...@gmail.com; bhuvanendra.kum...@amd.com;
> serhiy.re...@gmail.com; jini.susan.geo...@gmail.com
> Subject: Re: [Lldb-commits] [PATCH] D91734: [FastISel] Flush local value
> map on every instruction
> 
> Note, lldb has a bunch of special handling for line 0 code.  For instance,
> when we are pushing a breakpoint past the prologue we will keep pushing it
> forward over line number 0 lines.  Those are compiler generated and in
> general people don't want to stop there.  Similarly, if you are stepping
> through line 3 and the next line entry after 3 is line 0 we keep stepping
> till we get to a non-zero line.
> 
> When the compiler is actually using line 0 to mean "compiler generated
> code not really associated with a particular line, then I am pretty sure
> the debugger has to be aware of this or debugging is going to be a bit
> awkward...
> 
> I don't know if that's directly relevant to this bug, I haven't had time
> to follow the whole discussion.  But I'm not convinced all the problems
> with line 0 emission causing debugging oddities can be solved in the line
> table generation.
> 
> Jim

Hi Jim,

This issue is not really "line 0 causing debugger oddities" so much as
"line 0 attached to instructions that should have a real line number."

It's true that gdb's response to line 0 on the first instruction past
the prologue_end seems a tad idiosyncratic, but if nothing else, it
exposed an issue in the compiler that is worth solving.  There are
clearly instructions attributed to line 0 that shouldn't be, and the
goal here is to make that better.

Thanks,
--paulr
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] 1fae85a - [DWARF] Add instructions to regenerate this test, if needed.

[Robinson, Paul via lldb-commits]

Hi Davide,

I reread the review, and I see I was confused by two things:
(1) the name of the test is static_scope.s even though what it's testing is the 
scope of a var with a const_value, nothing to do with `static`;
(2) there's this comment in the review: https://reviews.llvm.org/D77698#1973122 
"what's the DWARF'y way to find out whether a variable is static?" suggesting 
you did care about static-scope variables.

I suggest renaming the test to better reflect what it's testing (which has 
nothing to do with the scope of static vars).

Re your question, DWARF doesn't explicitly identify variables as static.  
Variables have scopes, which might be local or might be file-level or might be 
global.  Globals are distinguished from file-level locals with the external 
flag.  Locals and file-level vars simply are in the appropriate scope.  A 
static local should look exactly like a non-static local, except that its 
location expression(s) would not be frame-based.  Static locals are not 
exciting, from a DWARF viewpoint.  (LLVM historically has had trouble putting 
them in the correct scope, but that is a compiler problem not a DWARF problem.)

I hope this resolves the questions/confusion.
Thanks,
--paulr

From: Davidino Italiano 
Sent: Thursday, April 16, 2020 5:26 PM
To: Robinson, Paul 
Cc: lldb-commits@lists.llvm.org
Subject: Re: [Lldb-commits] [lldb] 1fae85a - [DWARF] Add instructions to 
regenerate this test, if needed.




On Apr 16, 2020, at 2:01 PM, Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:




-Original Message-
From: lldb-commits 
mailto:lldb-commits-boun...@lists.llvm.org>>
 On Behalf Of
Davide Italiano via lldb-commits
Sent: Thursday, April 16, 2020 4:32 PM
To: lldb-commits@lists.llvm.org
Subject: [Lldb-commits] [lldb] 1fae85a - [DWARF] Add instructions to
regenerate this test, if needed.


Author: Davide Italiano
Date: 2020-04-16T13:31:32-07:00
New Revision: 1fae85a8534ec51ca893899314bd244b3e9684c7

URL: 
https://github.com/llvm/llvm-
project/commit/1fae85a8534ec51ca893899314bd244b3e9684c7
DIFF: 
https://github.com/llvm/llvm-
project/commit/1fae85a8534ec51ca893899314bd244b3e9684c7.diff

LOG: [DWARF] Add instructions to regenerate this test, if needed.

Added:


Modified:
   lldb/test/Shell/SymbolFile/DWARF/static_scope.s

Removed:



##
##
diff  --git a/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
b/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
index 84a69e08ecfc..02d497ac9ccb 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
+++ b/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
@@ -3,6 +3,15 @@

# REQUIRES: x86

+# Original test case (for future reference), compiled with:
+# $ clang-10 -g -Og test.c -o test
+# $ cat test.c
+# volatile int a;
+# main() {
+#   int b = 3;

Did you mean this to be `static`?
--paulr


No. Read the the review that introduced this test.


+#   a;
+# }
+
# RUN: llvm-mc -triple=x86_64-apple-macosx10.15.0 -filetype=obj %s > %t.o
# RUN: lldb-test symbols %t.o | FileCheck %s




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

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

Re: [Lldb-commits] [lldb] 1fae85a - [DWARF] Add instructions to regenerate this test, if needed.

[Robinson, Paul via lldb-commits]

> -Original Message-
> From: lldb-commits  On Behalf Of
> Davide Italiano via lldb-commits
> Sent: Thursday, April 16, 2020 4:32 PM
> To: lldb-commits@lists.llvm.org
> Subject: [Lldb-commits] [lldb] 1fae85a - [DWARF] Add instructions to
> regenerate this test, if needed.
> 
> 
> Author: Davide Italiano
> Date: 2020-04-16T13:31:32-07:00
> New Revision: 1fae85a8534ec51ca893899314bd244b3e9684c7
> 
> URL: https://github.com/llvm/llvm-
> project/commit/1fae85a8534ec51ca893899314bd244b3e9684c7
> DIFF: https://github.com/llvm/llvm-
> project/commit/1fae85a8534ec51ca893899314bd244b3e9684c7.diff
> 
> LOG: [DWARF] Add instructions to regenerate this test, if needed.
> 
> Added:
> 
> 
> Modified:
> lldb/test/Shell/SymbolFile/DWARF/static_scope.s
> 
> Removed:
> 
> 
> 
> ##
> ##
> diff  --git a/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
> b/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
> index 84a69e08ecfc..02d497ac9ccb 100644
> --- a/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
> +++ b/lldb/test/Shell/SymbolFile/DWARF/static_scope.s
> @@ -3,6 +3,15 @@
> 
>  # REQUIRES: x86
> 
> +# Original test case (for future reference), compiled with:
> +# $ clang-10 -g -Og test.c -o test
> +# $ cat test.c
> +# volatile int a;
> +# main() {
> +#   int b = 3;

Did you mean this to be `static`?
--paulr

> +#   a;
> +# }
> +
>  # RUN: llvm-mc -triple=x86_64-apple-macosx10.15.0 -filetype=obj %s > %t.o
>  # RUN: lldb-test symbols %t.o | FileCheck %s
> 
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r319653 - Makefile.rules: compile all tests with -fno-limit-debug-info

[Robinson, Paul via lldb-commits]

> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Wednesday, December 06, 2017 4:09 AM
> To: Jason Molenda
> Cc: lldb-commits@lists.llvm.org; Robinson, Paul
> Subject: Re: [Lldb-commits] [lldb] r319653 - Makefile.rules: compile all
> tests with -fno-limit-debug-info
> 
> On 6 December 2017 at 01:54, Jason Molenda  wrote:
> > It looks like the macos testsuite on the bot is broken with this -
> >
> > http://lab.llvm.org:8080/green/view/LLDB/job/lldb/3086/
> >
> > On my desktop with a recent clang, it works fine.  But it seems like
> every test? most tests? are failing with
> >
> > error: parsing line table prologue at 0x (parsing ended around
> 0x
> >
> > messages now.
> >
> > When I run one test by hand on my system, I have the -fno-limit-debug-
> info flag:
> >
> > ./dotest.py -t -v -v
> ../packages//Python/lldbsuite/test/functionalities/breakpoint/auto_continu
> e/
> >
> >
> >
> > stdout:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc
> hain/usr/bin/clang -g -O0 -fno-builtin -arch x86_64  -
> I/Volumes/newwork/svn/lldb/packages/Python/lldbsuite/test/make/../../../..
> /../include -include
> /Volumes/newwork/svn/lldb/packages/Python/lldbsuite/test/make/test_common.
> h -I/Volumes/newwork/svn/lldb/packages/Python/lldbsuite/test/make/  -fno-
> limit-debug-info  -std=c99   -c -o main.o main.c
> >
> >
> >
> > I'm not sure if the bots are building against too new or too new a
> compiler - if we're looking at a bug or it just does something weird when
> given -fno-limit-debug-info?
> 
> I was able to reproduce this by running the tests against the
> top-of-tree clang (which is what that bot does). It's not all tests
> that break, just the ones using dSYM debug info.
> 
> While this patch is a reasonable first guess, it is actually *not* the
> source of the breakage. The culprit is
> , which was present in the same
> patchset. It seems this change makes clang emit different line table
> headers. After that, dsymutil fails to process the files because it
> detects a header mismatch (and lldb breaks because it cannot find the
> line table or it is corrupt). I've cc'ed Paul in case he has any
> insight.
> 
> Maybe dsymutil needs to be updated to handle the new line tables?
> 
> pl

When I committed D38002, it broke debuginfo-tests on greendragon
because it was using an older lldb and/or dsymutil that didn't know
how to parse v3 or v4 line-table headers.  Adrian Prantl pinned
the failing debuginfo-tests to v2 (change -g to -gdwarf-2) while that 
gets sorted out.

I expect the same thing is happening here.  The same workaround should
apply here; the long-term fix is to update dsymutil.

I really would rather not make the compiler pin line tables at v2 as
a special case for Darwin, or whatever.
--paulr
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D40211: Add comments to DWARFCompileUnit length fields/methods

[Robinson, Paul via lldb-commits]

FTR, the size of the compile-unit header also changed in DWARF version 5, 
independent of the 32/64 format.

On a different topic, I had thought there was a goal of nuking lldb's copy of 
the DWARFxxx headers and converting to use LLVM's?  Did I imagine this?  If I 
do remember that correctly, fiddling with lldb's copy doesn't make much sense.
--paulr

From: lldb-commits [mailto:lldb-commits-boun...@lists.llvm.org] On Behalf Of 
Zachary Turner via lldb-commits
Sent: Monday, November 20, 2017 8:17 AM
To: Greg Clayton
Cc: Jan Kratochvil via Phabricator; lldb-commits@lists.llvm.org; 
reviews+d40211+public+c1500ec8aeff1...@reviews.llvm.org; 
jdevliegh...@apple.com; jan.kratoch...@redhat.com
Subject: Re: [Lldb-commits] [PATCH] D40211: Add comments to DWARFCompileUnit 
length fields/methods

You can make structs that are host and byte-order independent, LLVM is filled 
with stuff like this.  And while you might end up processing the information 
off in a way that it can be stored in a single compile unit without such a 
struct, it still can be useful when you're actually *doing* the parsing.

For one, it serves as documentation of the format.  It sounds like in order to 
know what a DWARF64 header looks like currently, I have to go read the code 
that actually parses one, which might require me to understand several 
functions and follow some pointer arithmetic and various other stuff.

Second, it can converts code like this:
```
if (m_dwarf64) {
  // read the first field
  // adjust a pointer
  // read the second field
  // adjust a pointer
  // read the third field
  // adjust a pointer
  ...

  // store the fields in the CompileUnit
} else {
  // read the first field
  // adjust a pointer
  // read the second field
  // adjust a pointer
  // read the third field
  // adjust a pointer
  ...
  // store the fields in the CompileUnit
}
```
into this:
```
if (m_dwarf64) {
  DWARF64_HEADER h;
  readStructure(h);
  // store the fields in the CompileUnit
} else {
  DWARF32_HEADER h;
  readStructure(h);
  // store the fields in the CompileUnit
}
```

Anyway, you answered my question, which is that we don't have one

On Mon, Nov 20, 2017 at 8:07 AM Greg Clayton 
mailto:clayb...@gmail.com>> wrote:
sizeof(struct) tends to include system level padding for the current host. But 
to answer your question, no there isn't a structure defined like this and we 
wouldn't use them anyway as we want to fill out one compile unit struct that 
works for both.

On Nov 20, 2017, at 8:01 AM, Zachary Turner 
mailto:ztur...@google.com>> wrote:

Right but isn’t there a DWARF64_HEADER and DEARF32_HEADER struct somewhere? 
This way you could just say

return m_isdwarf64 ? sizeof(DWARF64_HEADER) : sizeof(DWARF32_HEADER);
On Mon, Nov 20, 2017 at 7:50 AM Greg Clayton 
mailto:clayb...@gmail.com>> wrote:

On Nov 19, 2017, at 4:56 PM, Zachary Turner 
mailto:ztur...@google.com>> wrote:


On Sun, Nov 19, 2017 at 6:35 AM Jan Kratochvil via Phabricator via lldb-commits 
mailto:lldb-commits@lists.llvm.org>> wrote:
This revision was automatically updated to reflect the committed changes.
Closed by commit rL318626: Add comments to DWARFCompileUnit length 
fields/methods (authored by jankratochvil).

Changed prior to commit:
  https://reviews.llvm.org/D40211?vs=123472&id=123498#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D40211

Files:
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h


Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
@@ -41,26 +41,24 @@
   void Clear();
   bool Verify(lldb_private::Stream *s) const;
   void Dump(lldb_private::Stream *s) const;
+  // Offset of the initial length field.
   dw_offset_t GetOffset() const { return m_offset; }
   lldb::user_id_t GetID() const;
-  uint32_t Size() const {
-return m_is_dwarf64 ? 23
-: 11; /* Size in bytes of the compile unit header */
-  }
+  // Size in bytes of the initial length + compile unit header.
+  uint32_t Size() const { return m_is_dwarf64 ? 23 : 11; }

This is pretty gross.  Don't we have a structure somewhere that represents a 
compile unit header?  That we can just call sizeof on?  Same goes for the rest 
of the patch

It varies depending on data on how the length unit is represented in the data 
stream. If the length starts with UINT32_MAX, it is followed by a 64 bit 
length. If the length isn't UINT32_MAX it is just a 32 bit length.

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

Re: [Lldb-commits] [PATCH] D33504: Fix FDE indexing while scan debug_info section

[Robinson, Paul via lldb-commits]

IANA lldb developer, but I should think lldb would want to understand a 
DWARF 4 .debug_frame section.  (And it didn't change in DWARF 5, either!)
--paulr

> -Original Message-
> From: lldb-commits [mailto:lldb-commits-boun...@lists.llvm.org] On Behalf
> Of Pavel Labath via lldb-commits
> Sent: Thursday, May 25, 2017 9:17 AM
> To: Tatyana Krasnukha
> Cc: lldb-commits@lists.llvm.org
> Subject: Re: [Lldb-commits] [PATCH] D33504: Fix FDE indexing while scan
> debug_info section
> 
> +lldb-commits
> 
> Yes, that is certainly a viable approach. If there is a subset of
> dwarf that we are capable of parsing correctly then it would be great
> to enable that.
> 
> On 25 May 2017 at 16:46, Tatyana Krasnukha
>  wrote:
> > This binary uses DWARF 4, that introduces two additional fields in CIE -
> address_size and segment_size just after augmentation field. That’s why
> values are parsed  incorrectly.
> > May be we should discard unwind plan if there is unsupported dwarf
> version for now?
> >
> > Thanks,
> > Tatyana
> >
> > -Original Message-
> > From: Pavel Labath [mailto:lab...@google.com]
> > Sent: Thursday, 25 May, 2017 5:45 PM
> > To: tatyana.krasnu...@synopsys.com
> > Subject: Re: [PATCH] D33504: Fix FDE indexing while scan debug_info
> section
> >
> > Hey, try the attached binary for size.
> >
> > It was generated from the source file in
> lldb/test/testcases/functionalities/breakpoint/breakpoint_conditions/main.
> c,
> > while targetting android arm64.
> >
> > You should be able to create a test binary for yourself locally
> (assuming you're on linux) like this:
> > $ cat a.c
> > int a(char *x) { return *x; }
> >
> > int f() {
> >   return a(0);
> > }
> >
> > int g() {
> >   return 1+f();
> > }
> >
> > int _start() { return 2+g(); }
> >
> > $ clang -fno-exceptions -fno-unwind-tables -g a.c -nostdlib
> >
> > If you debug the binary with and stop in the ParseCIE function, you will
> see that it parses the entry incorrectly:
> > Process 39688 stopped
> > * thread #1, name = 'lldb', stop reason = step over
> > frame #0: 0x7074bb53
> >
> liblldb.so.5`lldb_private::DWARFCallFrameInfo::ParseCIE(this=0x006
> 13280,
> > cie_offset=0) at DWARFCallFrameInfo.cpp:303
> >300cie_sp->data_align = (int32_t)m_cfi_data.GetSLEB128(&offset);
> >301cie_sp->return_addr_reg_num = m_cfi_data.GetU8(&offset);
> >302
> > -> 303if (cie_sp->augmentation[0]) {
> >304  // Get the length of the eh_frame augmentation data
> >305  // which starts with a ULEB128 length in bytes
> >306  const size_t aug_data_len =
> (size_t)m_cfi_data.GetULEB128(&offset);
> >
> > (lldb) fr var cie_sp._M_ptr[0]
> > (lldb_private::DWARFCallFrameInfo::CIE) cie_sp._M_ptr[0] = {
> >   cie_offset = 0
> >   version = '\x04'
> >   augmentation = ""
> >   code_align = 8 <== wrong
> >   data_align = 0 <== wrong
> >   return_addr_reg_num = 1 <= wrong
> >   inst_offset = 0
> >   inst_length = 0
> >   ptr_encoding = '\0'
> >   lsda_addr_encoding = '\xff'
> >   personality_loc = 18446744073709551615
> >   initial_row = {
> > m_offset = 0
> > m_cfa_value = {
> >   m_type = unspecified
> >   m_value = {
> > reg = (reg_num = 0, offset = 0)
> > expr = (opcodes = 0x, length = 0)
> >   }
> > }
> > m_register_locations = size=0 {}
> >   }
> > }
> >
> > Correct parsing can be seen by running
> > $ llvm-dwarfdump a.out
> > .
> > .debug_frame contents:
> >
> >  0014  CIE
> >   Version:   4
> >   Augmentation:  ""
> >   Address size:  8  <=== this shows up in code_align
> >   Segment desc size: 0 <=== this shows up in data_align
> >   Code alignment factor: 1 <=== this shows up in return_addr_reg_num
> >   Data alignment factor: -8
> >   Return address column: 16
> >
> >   DW_CFA_def_cfa: reg7 +8
> >   DW_CFA_offset: reg16 -8
> >   DW_CFA_nop:
> >   DW_CFA_nop:
> >   DW_CFA_nop:
> >   DW_CFA_nop:
> >
> > 0018 001c  FDE cie= pc=004000b0...004000c1
> >   DW_CFA_advance_loc: 1
> >   DW_CFA_def_cfa_offset: +16
> >   DW_CFA_offset: reg6 -16
> >   DW_CFA_advance_loc: 3
> >   DW_CFA_def_cfa_register: reg6
> > 
> >
> >
> > Interestingly, in the x86_64 linux case, lldb still manages to unwind
> correctly despite the bad parsing.
> >
> >
> >
> >
> > On 25 May 2017 at 14:40, Tatyana Krasnukha via Phabricator
>  wrote:
> >> tatyana-krasnukha added a comment.
> >>
> >> Yes, give those binaries, please.
> >>
> >>
> >> Repository:
> >>   rL LLVM
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_
> >> D33504&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=8NZfjV_ZLY_S7gZyQMq8mj7tiN4
> >> vlymPiSt0Wl0jegw&m=Ze6ANiK7goV6lSPJcY8QglIJ_tZC0gXeUuqpQ8n4K40&s=1vfSh
> >> WELC8pd8-DQmAeW3QJDQgdMAJvn905_U-jVphM&e=
> >>
> >>
> >>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/c

[Lldb-commits] [PATCH] Fix Ubuntu build break with gcc 5.4

[Robinson, Paul via lldb-commits]

Recently I started seeing a build error from a tree that has lldb in it;
I don't know whether the problem is my configuration, or Ubuntu, or gcc, 
or what, but gcc complains that it can't convert 'int' to 'sigset_t' on 
the return statement.

This naïve one-liner fixes it, although I don't know anything about
signal stuff.  Didn't seem worth cranking up a Phab review for this...
--paulr

Index: source/Host/common/MainLoop.cpp
===
--- source/Host/common/MainLoop.cpp (revision 301939)
+++ source/Host/common/MainLoop.cpp (working copy)
@@ -155,7 +155,7 @@
 
 sigset_t MainLoop::RunImpl::get_sigmask() {
 #if SIGNAL_POLLING_UNSUPPORTED
-  return 0;
+  return sigset_t();
 #else
   sigset_t sigmask;
   int ret = pthread_sigmask(SIG_SETMASK, nullptr, &sigmask);


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

Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Robinson, Paul via lldb-commits]

> > I think we could emulate any pre-commit hook we like via GitHub
> > WebHooks by having two repositories: llvm and llvm-staging (say).
> >
> > People push to llvm-staging, which notifies some LLVM server we own.
> > That does basic sanity checks and pushes to llvm proper if passed.
> 
> I think that would be terrible in practice, for instance how do you handle
> situations like:
> 
> 1) Dev A push commit A
> 2) Dev B push commit B that changes some lines close to the one changed by
> commit A
> 3) sanity check fails on commit A, but llvm-staging contains A and B and
> can’t get rid of A easily because B would not apply without A.
> 
> At this point Dev B gets an email (or other mechanism, I don’t know what
> you imagined) telling that his changed are rejected for no good reason.
> 
> Also reverting to a state "before A” on llvm-staging would mean that that
> the history would be rewritten and everyone that pulled/fetched in the
> meantime would suffer .
> 
> If we want to go towards pre-check using staging, I believe we should work
> with pull-request (we’d still have the issue of conflicting PR, but I
> don’t believe it’d be that bad in practice).
> That’d be welcome, but that’d also be a whole other story to setup and
> maintain!
> 
> —
> Mehdi

Hear hear.  The schemes to handle this that I'm aware of do look more like
pull requests.  You submit your change to the pre-qualification queue.
If it rebases cleanly and passes pre-qual, your change becomes the new HEAD.
If it doesn't rebase cleanly or fails pre-qual, your change gets bounced.

A pull-request-like model also helps avoid the rebase-build-test-push(fail)
loop that you can get into with a very active git-based project.  This is
a mechanical task best suited to automation rather than wasting valuable
developer time on it.  But I suspect GitHub does not have anything like
this OOB so it would be an enhancement for a later time.
--paulr

P.S. At Sony we are building a system with a "staging" step but it's not
for our own work... more of a "flood control" dam.  :-)

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