[lldb-dev] [Bug 47083] New: then-branch and else-branch of the same if-statement should not be the same.（llvm-project/lldb/source/Symbol/ArmUnwindInfo.cpp:line 316 ）
https://bugs.llvm.org/show_bug.cgi?id=47083
Bug ID: 47083
Summary: then-branch and else-branch of the same if-statement
should not be the
same.（llvm-project/lldb/source/Symbol/ArmUnwindInfo.cp
p:line 316 ）
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: i...@ustchcs.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
then-branch and else-branch of the same if-statement should not be the same.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/lldb/source/Symbol/ArmUnwindInfo.cpp:line 316
316 } else if ((byte1 & 0xc0) == 0xc0) {
317// 11xxxyyy Spare (xxx != 000, 001, 010)
318return false;
319 } else {
320return false;
321 }
322}
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-2.1: then-branch and else-branch of the same if-statement should not
be the same.)
--
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 47086] New: A project should not contain unreachable code.(llvm-project/lldb/source/Breakpoint/BreakpointResolverAddress.cpp:line 90)
https://bugs.llvm.org/show_bug.cgi?id=47086
Bug ID: 47086
Summary: A project should not contain unreachable
code.(llvm-project/lldb/source/Breakpoint/BreakpointRe
solverAddress.cpp:line 90)
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: i...@ustchcs.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
A project should not contain unreachable code.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/lldb/source/Breakpoint/BreakpointResolverAddress.cpp:line 90
70if (section_sp) {
71 ModuleSP module_sp = section_sp->GetModule();
72 ConstString module_name;
73 if (module_sp)
74module_name.SetCString(module_name.GetCString());
75
76 options_dict_sp->AddStringItem(GetKey(OptionNames::ModuleName),
77 module_name.GetCString());
78 options_dict_sp->AddIntegerItem(GetKey(OptionNames::AddressOffset),
79 m_addr.GetOffset());
80} else {
81 options_dict_sp->AddIntegerItem(GetKey(OptionNames::AddressOffset),
82 m_addr.GetOffset());
83 if (m_module_filespec) {
84options_dict_sp->AddStringItem(GetKey(OptionNames::ModuleName),
85 m_module_filespec.GetPath());
86 }
87}
88
89return WrapOptionsDict(options_dict_sp);
90return StructuredData::ObjectSP();
91 }
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-1.1: A project should not contain unreachable code.)
--
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 47086] A project should not contain unreachable code.(llvm-project/lldb/source/Breakpoint/BreakpointResolverAddress.cpp:line 90)
https://bugs.llvm.org/show_bug.cgi?id=47086 Raphael Isemann changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||teempe...@gmail.com --- Comment #1 from Raphael Isemann --- Fixed in 8119d6c14695b436adb66f0d891863eeea9e62ad -- 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 47088] New: All allocated dynamic memory should be explicitly deallocated to avoid memory leaks.(llvm-project/lldb/source/Host/windows/Windows.cpp:line 146)
https://bugs.llvm.org/show_bug.cgi?id=47088
Bug ID: 47088
Summary: All allocated dynamic memory should be explicitly
deallocated to avoid memory
leaks.(llvm-project/lldb/source/Host/windows/Windows.c
pp:line 146)
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: i...@ustchcs.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
All allocated dynamic memory should be explicitly deallocated to avoid memory
leaks.Before return on line 146, the memory allocated on line 130 is not freed.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/lldb/source/Host/windows/Windows.cpp:line 146
141wchar_t wideFullPathBuffer[PATH_MAX];
142wchar_t *wideFullPath;
143if ((wideFullPath = _wfullpath(wideFullPathBuffer, wideName,
PATH_MAX)) ==
144NULL) {
145 errno = ENAMETOOLONG;
146 return NULL;
147}
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-13.19: All allocated dynamic memory should be explicitly deallocated
to avoid memory leaks.)
--
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 47089] New: The use of if (Condition) {...} else if (Condition) {...} pattern should be avoided.(llvm-project/lldb/source/Plugins/Language/ObjC/NSArray.cpp:line 826)
https://bugs.llvm.org/show_bug.cgi?id=47089
Bug ID: 47089
Summary: The use of if (Condition) {...} else if (Condition)
{...} pattern should be
avoided.(llvm-project/lldb/source/Plugins/Language/Obj
C/NSArray.cpp:line 826)
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: i...@ustchcs.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
The use of if (Condition) {...} else if (Condition) {...} pattern should be
avoided.
Code on line 827 cannot be executed.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/lldb/source/Plugins/Language/ObjC/NSArray.cpp:line 826
814if (class_name == g_NSArrayI) {
815 if (runtime->GetFoundationVersion() >= 1436)
816return (new
Foundation1436::NSArrayISyntheticFrontEnd(valobj_sp));
817 if (runtime->GetFoundationVersion() >= 1430)
818return (new
Foundation1430::NSArrayISyntheticFrontEnd(valobj_sp));
819 else
820return (new
Foundation1300::NSArrayISyntheticFrontEnd(valobj_sp));
821} else if (class_name == g_NSArrayI_Transfer) {
822return (new
Foundation1436::NSArrayI_TransferSyntheticFrontEnd(valobj_sp));
823} else if (class_name == g_NSArray0) {
824} else if (class_name == g_NSFrozenArrayM) {
825 return (new
Foundation1436::NSFrozenArrayMSyntheticFrontEnd(valobj_sp));
826} else if (class_name == g_NSArray0) {
827 return (new NSArray0SyntheticFrontEnd(valobj_sp));
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-2.2: The use of if (Condition) {...} else if (Condition) {...}
pattern should be avoided.)
--
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] RFC: AArch64 Linux Memory Tagging Support for LLDB
Hi all,
What follows is my proposal for supporting AArch64's memory tagging
extension in LLDB. I think the link in the first paragraph is a good
introduction if you haven't come across memory tagging before.
I've also put the document in a Google Doc if that's easier for you to
read:
https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing
(please keep comments to this list though)
Any and all comments welcome. Particularly I would like opinions on
the naming of the commands, as this extension is AArch64 specific but
the concept of memory tagging itself is not.
(I've added some people on Cc who might have particular interest)
Thanks,
David Spickett.
# RFC: AArch64 Linux Memory Tagging Support for LLDB
## What is memory tagging?
Memory tagging is an extension added in the Armv8.5-a architecture for AArch64.
It allows tagging pointers and storing those tags so that hardware can validate
that a pointer matches the memory address it is trying to access. These paired
tags are stored in the upper bits of the pointer (the “logical” tag) and in
special memory in hardware (the “allocation” tag). Each tag is 4 bits in size.
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety
## Definitions
* memtag - This is the clang name for the extension as in
“-march=armv8.5-a+memtag”
* mte - An alternative name for mmtag, also the llvm backend name for
the extension.
This document may use memtag/memory tagging/MTE at times, they mean
the same thing.
* logical tag - The tag stored inside a pointer variable (accessible
via normal shift and mask)
* allocation tag - The tag stored in tag memory (which the hardware provides)
for a particular tag granule
* tag granule - The amount of memory that a single tag applies to,
which is 16 bytes.
## Existing Tool Support
* GCC/Clang can generate MTE instructions
* Clang has an option to memory tag the stack (discussed later)
* QEMU support has been merged
* Linux Kernel patches are in progress
(git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
“devel/mte-v5” branch)
* GDB support is in review and this design takes a lot of direction from that
(https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/luisgpm/aarch64-mte-v2)
(originally proposed
https://sourceware.org/pipermail/gdb-patches/2019-August/159881.html)
## New lldb features
Assuming your software is acting correctly, memory tagging can “just work”
without debugger support. This assumes the compiler/toolchain/user are
always correct.
For when that isn’t the case we want to be able to:
* Read/write the logical tags in a pointer
* Read/write the allocation tags assigned to a given area of memory
* Test whether the logical tag in a pointer matches the allocation tag of the
memory it refers to
* Read/write memory even when tags are mismatched
The most obvious use case for this is working through issues where bugs in the
toolchain don’t generate correct code. On the other hand there’s a good case for
deliberately messing with pointers in your code to prove that such protection
actually works.
Note: potential extensions to scripting such as tags as attributes of values and
such are not being proposed here. Of course the new commands will be
added in the
standard ways so you can use those.
## New Commands
### Command Availability
Note: commands will be listed in tab completion and help regardless of
these checks
* The remote server must support memory tagging packets. lldb will send/check
for the “memory-tagging” feature in the qSupported packet. (this
name aligns with gdb)
* The process must have MTE available. We check HWCAP2_MTE for this.
* The process must have enabled tagged addressing using prctl
(see “New Registers” for details)
* The address given must be in a range that has MTE enabled, since you can mmap
with or without MTE. (this information is in /proc/.../smaps)
Interaction With Clang’s Stack Tagging
We’re relying on the kernel to tell us if MTE is enabled, so stack tagging will
not be visible to the debugger this way.
(https://github.com/google/sanitizers/wiki/Stack-instrumentation-with-ARM-Memory-Tagging-Extension-(MTE))
E.g. {int x; use(&x); } where x is void x(int* ptr);
“ptr” will have a memory tag but the kernel won’t know this.
To work around this a setting will be added to tell lldb to assume that MTE is
enabled, so that you can at least see the logical tags of a pointer.
(see “New Settings”)
### General Properties/Errors
* must resolve to some value that can be handled as an
address by lldb. (though it need not be a pointer specifically)
* Tags will be printed in hexadecimal to reflect the fact that they are a 4 bit
field. (and since tags are randomly generated, ordering is unlikely
to be a concern)
* Packed tags will be 1 tag per byte (matches what ptrace expects)
* Addresses will be rounded down to the nearest granule (not always by ll
[lldb-dev] [Bug 47088] All allocated dynamic memory should be explicitly deallocated to avoid memory leaks.(llvm-project/lldb/source/Host/windows/Windows.cpp:line 146)
https://bugs.llvm.org/show_bug.cgi?id=47088 Raphael Isemann changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- 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 47089] The use of if (Condition) {...} else if (Condition) {...} pattern should be avoided.(llvm-project/lldb/source/Plugins/Language/ObjC/NSArray.cpp:line 826)
https://bugs.llvm.org/show_bug.cgi?id=47089 Jonas Devlieghere changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonas Devlieghere --- commit b8ff0daeac0752689ffca9345686845d1b7cfed8 Author: Jonas Devlieghere Date: Mon Aug 10 09:38:14 2020 -0700 [lldb] Fix NSArray0 data formatter and add test Fixes PR47089 -- 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] RFC: AArch64 Linux Memory Tagging Support for LLDB
Hi David, thanks for the great writeup. I hadn't been following the gdb MTE support. This all looks reasonable to me. A few quick thoughts -- The initial idea of commands like "memory showptrtag", "memory showtag", "memory checktag" - it might be better to put all of these under "memory tag ...", similar to how "breakpoint command ..." works. It makes sense to have lldb read/write the control pseudo-register as if it were a normal reg, in its own register grouping. You mentioned that you had some thoughts about how to make it more readable to users - I know this is something Greg has been hoping to do / see done at some point, for control registers where we could annotate the registers a lot better. I noticed that qemu for x86 provides exactly this kind of annotation information in its register target.xml definitions (v. lldb/test/API/functionalities/gdb_remote_client/TestRegDefinitionInParts.py ) but I don't THINK we do anything with these annotations today. Not at all essential to this work, but just noting that this is something we all would like to see better support for. As for annotating the reason the program stopped on an MTE exception, Ismail was working on something similar in the past - although as you note, the really cool thing would be decoding the faulting instruction to understand what target register was responsible for the fault (and maybe even working back via the debug info to figure out what user-level variable it was??) to annotate it, which is something we're not doing anywhere right now. There was a little proof-of-concept thing that Sean Callanan did years ago "frame diagnose" which would try to annotate to the user in high-level source terms why a fault happened, but I think it was using some string matching of x86 instructions to figure out what happened. :) We're overdue to upstream the PAC support for lldb that we're using, it's dependent on some other work being upstreamed that hasn't been done yet, but the general scheme involves querying the lldb-server / debugserver / corefile to get the number of bits used for virtual addressing, and then it just stomps on all the other high bits when trying to dereference values. If you do 'register read' of a function pointer, we show the actual value with PAC bits, then we strip the PAC bits off and if it resolves to a symbol, we print the stripped value and symbol that we're pointing to. It seems similar to what MTE will need -- if you have a variable pointing to heap using MTE, and you do `x/g var`, lldb should strip off the MTE bits before sending the address to read to lldb-server. The goal with the PAC UI design is to never hide the PAC details from the user, but to additionally show the PAC-less address when we're sure that it's an address in memory. Tougher to do that with MTE because we'll never be pointing to a symbol, it will be heap or stack. J > On Aug 10, 2020, at 3:41 AM, David Spickett via lldb-dev > wrote: > > Hi all, > > What follows is my proposal for supporting AArch64's memory tagging > extension in LLDB. I think the link in the first paragraph is a good > introduction if you haven't come across memory tagging before. > > I've also put the document in a Google Doc if that's easier for you to > read: > https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing > (please keep comments to this list though) > > Any and all comments welcome. Particularly I would like opinions on > the naming of the commands, as this extension is AArch64 specific but > the concept of memory tagging itself is not. > (I've added some people on Cc who might have particular interest) > > Thanks, > David Spickett. > > > > # RFC: AArch64 Linux Memory Tagging Support for LLDB > > ## What is memory tagging? > > Memory tagging is an extension added in the Armv8.5-a architecture for > AArch64. > It allows tagging pointers and storing those tags so that hardware can > validate > that a pointer matches the memory address it is trying to access. These paired > tags are stored in the upper bits of the pointer (the “logical” tag) and in > special memory in hardware (the “allocation” tag). Each tag is 4 bits in size. > > https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety > > ## Definitions > > * memtag - This is the clang name for the extension as in > “-march=armv8.5-a+memtag” > * mte - An alternative name for mmtag, also the llvm backend name for > the extension. > This document may use memtag/memory tagging/MTE at times, they mean > the same thing. > * logical tag - The tag stored inside a pointer variable (accessible > via normal shift and mask) > * allocation tag - The tag stored in tag memory (which the hardware provides) > for a particular tag granule > * tag granule - The amount of memory that a single tag applies to, > which is 16 bytes. > > ## Existing Tool Support > > * GCC/
[lldb-dev] [Bug 47100] New: A project should not contain unreachable code.(Code is commented out partially)(project/lldb/source/Plugins/Platform/MacOSX/PlatformRemoteAppleBridge.cpp:line 101)
https://bugs.llvm.org/show_bug.cgi?id=47100
Bug ID: 47100
Summary: A project should not contain unreachable code.(Code is
commented out
partially)(project/lldb/source/Plugins/Platform/MacOSX
/PlatformRemoteAppleBridge.cpp:line 101)
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: i...@ustchcs.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
A project should not contain unreachable code.(Code is commented out partially)
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/lldb/source/Plugins/Platform/MacOSX/PlatformRemoteAppleBridge.cpp:
line 101
98if (create) {
99 switch (triple.getOS()) {
100 // NEED_BRIDGEOS_TRIPLE case llvm::Triple::BridgeOS:
101break;
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-1.1: A project should not contain unreachable code.)
--
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 47101] New: LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.(llvm-project/lldb/source/Plugi
https://bugs.llvm.org/show_bug.cgi?id=47101 Bug ID: 47101 Summary: LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.(llvm-project/lldb/source/Plugins/Symbo lFile/DWARF/AppleDWARFIndex.cpp:line 45 ) Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: i...@ustchcs.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression. (Perhaps, duplicated sub-conditions are introduced by copy-paste.) commit e3546c78cabfbf670391a57766872f0a8e28a423 llvm-project/lldb/source/Plugins/SymbolFile/DWARF/AppleDWARFIndex.cpp:line 45 45if (apple_names_table_up || apple_names_table_up || apple_types_table_up || 46apple_objc_table_up) 47 return std::make_unique( 48 module, std::move(apple_names_table_up), 49 std::move(apple_namespaces_table_up), std::move(apple_types_table_up), 50 std::move(apple_objc_table_up)); 51 52return nullptr; 53 } Reported by: Ustchcs Toolsets Bugfinder (bugfinder-2.3: LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.) -- 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 47101] LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.(llvm-project/lldb/source/Plugins/Sy
https://bugs.llvm.org/show_bug.cgi?id=47101 Jonas Devlieghere changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonas Devlieghere --- Fixed in b448eda4066ff5dee2517018e386893ab629f9e8. -- 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 47100] A project should not contain unreachable code.(Code is commented out partially)(project/lldb/source/Plugins/Platform/MacOSX/PlatformRemoteAppleBridge.cpp:line 101)
https://bugs.llvm.org/show_bug.cgi?id=47100 Jonas Devlieghere changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonas Devlieghere --- Tatyana fixed this in bc056b3aa7130923ab9ad0505c5a8d65ea721e39 -- 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
