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

RepoTicketGenerationPass is not the first pass to run #6

Open
gregbedwell opened this issue Jun 13, 2018 · 0 comments
Open

RepoTicketGenerationPass is not the first pass to run #6

gregbedwell opened this issue Jun 13, 2018 · 0 comments

Comments

@gregbedwell
Copy link

It seems the intention is that RepoTicketGenerationPass should run prior to any optimization passes, however it can be seen that some function passes actually run prior to it at clang -O2.

$ build-vs2015-ps4-ninja\bin\clang.exe --version
clang version 6.0.0 (https://github.com/SNSystems/clang-prepo.git 85663ce2d0e357504b3b92e3cdf53b39056d1f7e) (https://github.com/SNSystems/llvm-prepo.git 7abce79f1eaf0717468bce6c5bf7f2853bfd6355)
Target: x86_64-scei-ps4
Thread model: posix
InstalledDir: e:\work\prepo\build-vs2015-ps4-ninja\bin

$ type 1.cpp
int f(int x) {
  return x*2;
}


int g(int x) {
  return g(x) * g(x + 1);
}

$ build-vs2015-ps4-ninja\bin\clang.exe -c -O2 1.cpp -mllvm -opt-bisect-limit=100000
BISECT: running pass (1) Simplify the CFG on function (_Z1fi)
BISECT: running pass (2) SROA on function (_Z1fi)
BISECT: running pass (3) Early CSE on function (_Z1fi)
BISECT: running pass (4) Simplify the CFG on function (_Z1gi)
BISECT: running pass (5) SROA on function (_Z1gi)
BISECT: running pass (6) Early CSE on function (_Z1gi)
BISECT: running pass (7) RepoTicketGenerationPass on module (1.cpp)
BISECT: running pass (8) RepoPruningPass on module (1.cpp)
BISECT: running pass (9) Infer set function attributes on module (1.cpp)
BISECT: running pass (10) Interprocedural Sparse Conditional Constant Propagation on module (1.cpp)
...
@rgal rgal transferred this issue from SNSystems/llvm-prepo Feb 21, 2019
rgal pushed a commit that referenced this issue Apr 15, 2020
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>

llvm-svn: 366378
rgal pushed a commit that referenced this issue Jun 11, 2020
…t binding

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

GDB has some more complicated preferences between overlapping and/or sharing
address symbols, I have made here so far the most simple fix for this case.

Differential revision: https://reviews.llvm.org/D63540
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant