Skip to content
This repository has been archived by the owner on Jan 6, 2022. It is now read-only.

mulle-lldb shows errors on startup on darwin #6

Open
mulle-nat opened this issue Aug 10, 2018 · 1 comment
Open

mulle-lldb shows errors on startup on darwin #6

mulle-nat opened this issue Aug 10, 2018 · 1 comment

Comments

@mulle-nat
Copy link

It hangs immediately after run: How to reproduce:

b main
run

Should check, if even the regular lldb works.
@mulle-nat mulle-nat changed the title mulle-lldb does not work on darwin mulle-lldb shows errors on startup on darwin Aug 12, 2018
@mulle-nat
Copy link
Author

mulle-nat commented Aug 12, 2018 •
edited by codeon-nat
Loading

Actually that probably happened, because the binary wasn't properly signed.
The actual 6.0.0.3 built for homebrew works, but emits spurious warnings like this on start:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named lldb.embedded_interpreter
Traceback (most recent call last):
  File "<string>", line 1, in <module>

Which is probably python related. (#3 contains a possible fix)

codeon-nat pushed a commit that referenced this issue Oct 15, 2019
@jasonmolenda
RegisterContextLLDB::GetFullUnwindPlanForFrame has four verbose
f2e0eff 
logging messages that are written the same, making it difficult to
know for certain which code path was taken based on a logfile.  Add
some words to make each unique.

Right now the ordering for finding a FullUnwindPlan (ignoring
fallback unwind plan logic) is

1. If this is a _sigtramp like function, try eh_frame which is
   hand written on darwin systems to account for finding the
   saved register context correctly.

2. Ask the DynamicLoader if eh_frame should be preferred for
   this frame.  Some binaries on the system may have hand-written
   eh_frame and the DynamicLoader is the source for this.  (primarily
   this is for hand-written assembly in the objc runtime, and we tell
   lldb to trust that for functions in libobjc.dylib.)

3. if 0th frame, use GetUnwindPlanAtNonCallSite plan.

4. GetUnwindPlanAtCallSite {for 0th or any other}

5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.}

6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction

7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan


I'm moving #6 -- DefaultAtFunctionEntry -- up to between #3 and #4,
where we're already doing things specific to the zeroth frame.  If
we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan
has failed for some reason, and we're on the first instruction, we
should definitely use DefaultAtFunctionEntry instead of any other
unwind plan.  If we're trying to step out of some rando function
on the system that we couldn't assembly instruction inspect, this
is sufficient for us to step out of it.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@359847 91177308-0d34-0410-b5e6-96231b3b80d8
codeon-nat pushed a commit that referenced this issue Oct 15, 2019
@jankratochvil
Fix lookup of symbols at the same address with no size vs. size
c2d4319 
This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30):

PASS:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
  * frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325
    frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295
    frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
    frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
    frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
    frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
    frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243
    frame #7: 0x000000000040106e a.out`_start + 46

vs.

FAIL - unrecognized abort() function:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
  * frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325
    frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295
    frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
    frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
    frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
    frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
    frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243
    frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46

The extra ELF symbols are there due to Annobin (I did not investigate why this problem happened specifically since F-30 and not since F-28).
It is due to:

Symbol table '.dynsym' contains 2361 entries:
Valu e          Size Type   Bind   Vis     Name
0000000000022769   5 FUNC   LOCAL  DEFAULT _nl_load_domain.cold
000000000002276e   0 NOTYPE LOCAL  HIDDEN  .annobin_abort.c.unlikely
...
000000000002276e   0 NOTYPE LOCAL  HIDDEN  .annobin_loadmsgcat.c_end.unlikely
...
000000000002276e   0 NOTYPE LOCAL  HIDDEN  .annobin_textdomain.c_end.unlikely
000000000002276e 548 FUNC   GLOBAL DEFAULT abort
000000000002276e 548 FUNC   GLOBAL DEFAULT abort@@GLIBC_2.2.5
000000000002276e 548 FUNC   LOCAL  DEFAULT __GI_abort
0000000000022992   0 NOTYPE LOCAL  HIDDEN  .annobin_abort.c_end.unlikely

Differential Revision: https://reviews.llvm.org/D63540


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@364773 91177308-0d34-0410-b5e6-96231b3b80d8
codeon-nat pushed a commit that referenced this issue Oct 15, 2019
@jasonmolenda
Add support to ProcessMachCore::DoLoadCore to handle an EFI UUID str.
b194f34 
If a core file has an EFI version string which includes a UUID
(similar to what it returns for the kdp KDP_KERNELVERSION packet)
in the LC_IDENT or LC_NOTE 'kern ver str' load command.  In that
case, we should try to find the binary and dSYM for the UUID
listed.  The dSYM may have python code which knows how to relocate
the binary to the correct address in lldb's target section load
list and loads other ancillary binaries.

The test case is a little involved,

1. it compiles an inferior hello world apple (a.out),
2. it compiles a program which can create a corefile manually
   with a specific binary's UUID encoded in it,
3. it gets the UUID of the a.out binary,
4. it creates a shell script, dsym-for-uuid.sh, which will
   return the full path to the a.out + a.out.dSYM when called
   with teh correct UUID,
5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before
   creating the lldb target, to point to this dsym-for-uuid.sh,
6. runs the create-corefile binary we compiled in step #2,
7. loads the corefile from step #6 into lldb,
8. verifies that lldb loaded a.out by reading the LC_NOTE
   load command from the corefile, calling dsym-for-uuid.sh with
   that UUID, got back the path to a.out and loaded it.

whew!

<rdar://problem/47562911>



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@366378 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mulle-nat