Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated End-To-End Testing (Regression Tests) #4

Open
nforbus opened this issue Jan 25, 2019 · 39 comments
Open

Automated End-To-End Testing (Regression Tests) #4

nforbus opened this issue Jan 25, 2019 · 39 comments
Assignees
Labels

Comments

@nforbus
Copy link

nforbus commented Jan 25, 2019

Pursue a method to do end-to-end testing, as a means to treat the randstruct plugin as a blackbox.

@nforbus
Copy link
Author

nforbus commented Jan 26, 2019

Modified the poc/Makefile to include a tests flag. It creates two outputs, one with the plugin in use, and one without the plugin in use.

You can then run the test code that Cole added, select the filenames of the two output files, and it will output the difference between the two files in llvm IR.

@jeffreytakahashi
Copy link

Now looking at LLDB testing!
https://lldb.llvm.org/tutorial.html

As it turns out, the entire LLDB API is available via Python. This is the future:
https://lldb.llvm.org/python_reference/index.html

@nforbus
Copy link
Author

nforbus commented Jan 29, 2019

Updated the makefile commands to show the variable names for better readability. Cannot use the same method to create more human-readable test results though.

Embedding within CMake still to happen, more research needed because idk jack about CMake.

@jcantrell
Copy link

Figured out how to use lldb to find locations of struct memories to compare their locations when compiled with and without the plugin.

@jcantrell
Copy link

Working on a python script to automate this check and output 1 or 0 depending on if the structs were shuffled.

@jeffreytakahashi jeffreytakahashi self-assigned this Jan 29, 2019
@tim-pugh tim-pugh pinned this issue Jan 29, 2019
@tim-pugh
Copy link
Member

tim-pugh commented Jan 30, 2019

We'll be attending a unit testing workshop I've scheduled from 6:30pm until 8pm Jan 29th, 2019 at the Engineering Building. Google cal invite should be in the mail. We'll show up a hour early to prepare as a team.

@jcantrell
Copy link

The plan (as of Jan. 30) is to write a python script https://lldb.llvm.org/python-reference.html, https://lldb.llvm.org/varformats.html that wraps lldb, and use lldb's features to analyze order of structs of a test program or set of test programs.
Useful lldb commands:
target create "program"
process launch --stop-at-entry
thread continue
b filename:linenum (sets a breakpoint)
frame variable varname
frame var -L
l
l -

@connorkuehl connorkuehl transferred this issue from clang-randstruct/plugin Feb 4, 2019
@connorkuehl connorkuehl added this to the Minimum Viable Product milestone Feb 4, 2019
@connorkuehl connorkuehl changed the title End-To-End Testing Automated End-To-End Testing Feb 8, 2019
@tim-pugh tim-pugh added the MVP label Feb 12, 2019
@tim-pugh tim-pugh changed the title Automated End-To-End Testing Automated End-To-End Testing (Regression Tests) Feb 12, 2019
@tim-pugh
Copy link
Member

FYI I can (or from when I worked on it and am recalling) can run the test suite from within windows. It should be easy enough to do on the nix side, just haven't dug into it.

https://llvm.org/docs/TestingGuide.html

This should lead us in the correct direction though!

@tim-pugh tim-pugh self-assigned this Feb 14, 2019
@tim-pugh
Copy link
Member

make check-clang will run the test suite according to :
https://clang.llvm.org/get_started.html

These two docs should give us all we need I believe

@tim-pugh
Copy link
Member

Looks like this is the correct location to place any tests:
~llvm-project\clang\unittests\AST

@nforbus
Copy link
Author

nforbus commented Feb 20, 2019

Rebuilt my server, rebuilt clang, ran it with check-llvm in the build directory as required. Of all the regression tests, there was only one "unexpected failure". I'll look at it more tomm (in class today), and see if I can pinpoint the cause of the error. I believe that we can consider our regression tests passed as long as our final version doesn't trigger any unexpected errors with check-llvm.

@tim-pugh
Copy link
Member

tim-pugh commented Feb 21, 2019

screenshot from 2019-02-20 19-49-52

After editing the file located at
/home/timpugh_pdx_edu/llvm-project/clang/test/Misc/pragma-attribute-supported-attributes-list.test

it states the error is
:120:16: error: CHECK-NEXT: is not on the line after the previous match

@tim-pugh
Copy link
Member

tim-pugh commented Feb 21, 2019

I think Its based on alphabetical ordering, so I replaced the line and put it in that order and am waiting to confirm.

@tim-pugh
Copy link
Member

It is based on alphabetical ordering.

I managed to get a test to pass but it required running a slower machine, 16 CPU's.

The regression test for clang hung once before it passed.

I'm currently rebuilding upstream clang/llvm to see if this too hangs, although to save time I'm using a 64 CPU machine.

@nforbus
Copy link
Author

nforbus commented Feb 23, 2019

Installed the test suite and attempted to build. Cannot seem to build using more than a single core though. It made it to 37% and failed, and then failed multiple times when attempted to restart. Not sure on next path.

@tim-pugh
Copy link
Member

@nforbus Did you experience the same failure at 37%?

Mine complained about an xray header file not being in the proper location.

I believe the directions we followed may be deprecated, but there appears to be a different set we can follow.

https://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite

@tim-pugh
Copy link
Member

https://llvm.org/docs/ReleaseProcess.html

We may have to do a more sophisticated build process to run the test-suite.

1 similar comment
@tim-pugh
Copy link
Member

https://llvm.org/docs/ReleaseProcess.html

We may have to do a more sophisticated build process to run the test-suite.

@tim-pugh
Copy link
Member

https://llvm.org/docs/lnt/quickstart.html

This should and the above links should get the test suite going.

@tim-pugh
Copy link
Member

tim-pugh commented Feb 28, 2019

Having a bunch of errors getting the test suite working.

I believe this is because the test-suite isn't in lock step with the llvm-projects master branch (which appears to be their development branch more or less).

The Gameplan from here on out with this:

I'm building clang/llvm release 8
I'm building the test-suite release 8

Provided these two work together, I'll merge the randstruct code, and re-test

If at this point in the process it still works, we're prepared to hook our POC file into the test suite

If this goes according to plan and we accomplish it, then we'll know how to properly do it, and then will add our poc to the test-suites MASTER branch

This will ensure it works, to the best of our knowledge, regardless if the active development between the llvm/clang and the test-suite are not in lock step.

I'm currently having it built and if it fails, I'll have no more leads on how to get it working atm.

@tim-pugh
Copy link
Member

tim-pugh commented Feb 28, 2019

I have more leads now after mailing the devs and getting a response.

I included compiler-rt into the build and my build is progressing now. In the event things break in the future I think I'll just have to assemble the entire toolchain which includes:
compiler-rt , libunwind , libc++abi, libc++, lld (although lld may not be required)

More can be found here:
https://clang.llvm.org/docs/Toolchain.html#clang-frontend

and here:

https://stackoverflow.com/questions/47304919/building-and-using-a-pure-llvm-toolchain-for-c-on-linux

@tim-pugh
Copy link
Member

you will also need to install tcl

sudo apt-get install tcl

@tim-pugh
Copy link
Member

tim-pugh commented Mar 1, 2019

I've now created instructions in our team drive called BUILDING THE LLVM TEST SUITE (Linux) that solves this headache.

@tim-pugh
Copy link
Member

tim-pugh commented Mar 1, 2019

The test suite runs and passes all 918 tests.

This was with the release 8 build (both llvm/clang and the test-suite). We'll need to run it with randstruct now. I'm going to assume this is going to pass since we didn't mess with the clang internals very much except in record layout builder, and even then it should effect things unless we use our flag.

connorkuehl pushed a commit that referenced this issue Mar 1, 2019
Currently, the LLVM will print an error like
  Unsupported relocation: try to compile with -O2 or above,
  or check your static variable usage
if user defines more than one static variables in a single
ELF section (e.g., .bss or .data).

There is ongoing effort to support static and global
variables in libbpf and kernel. This patch removed the
assertion so user programs with static variables won't
fail compilation.

The static variable in-section offset is written to
the "imm" field of the corresponding to-be-relocated
bpf instruction. Below is an example to show how the
application (e.g., libbpf) can relate variable to relocations.

  -bash-4.4$ cat g1.c
  static volatile long a = 2;
  static volatile int b = 3;
  int test() { return a + b; }
  -bash-4.4$ clang -target bpf -O2 -c g1.c
  -bash-4.4$ llvm-readelf -r g1.o

  Relocation section '.rel.text' at offset 0x158 contains 2 entries:
      Offset             Info             Type               Symbol's Value  Symbol's Name
  0000000000000000  0000000400000001 R_BPF_64_64            0000000000000000 .data
  0000000000000018  0000000400000001 R_BPF_64_64            0000000000000000 .data
  -bash-4.4$ llvm-readelf -s g1.o

  Symbol table '.symtab' contains 6 entries:
     Num:    Value          Size Type    Bind   Vis      Ndx Name
       0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
       1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS g1.c
       2: 0000000000000000     8 OBJECT  LOCAL  DEFAULT    4 a
       3: 0000000000000008     4 OBJECT  LOCAL  DEFAULT    4 b
       4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
       5: 0000000000000000    64 FUNC    GLOBAL DEFAULT    2 test
  -bash-4.4$ llvm-objdump -d g1.o

  g1.o:   file format ELF64-BPF

  Disassembly of section .text:
  0000000000000000 test:
       0:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00         r1 = 0 ll
       2:       79 11 00 00 00 00 00 00         r1 = *(u64 *)(r1 + 0)
       3:       18 02 00 00 08 00 00 00 00 00 00 00 00 00 00 00         r2 = 8 ll
       5:       61 20 00 00 00 00 00 00         r0 = *(u32 *)(r2 + 0)
       6:       0f 10 00 00 00 00 00 00         r0 += r1
       7:       95 00 00 00 00 00 00 00         exit
  -bash-4.4$

  . from symbol table, static variable "a" is in section #4, offset 0.
  . from symbol table, static variable "b" is in section #4, offset 8.
  . the first relocation is against symbol #4:
    4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
    and in-section offset 0 (see llvm-objdump result)
  . the second relocation is against symbol #4:
    4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
    and in-section offset 8 (see llvm-objdump result)
  . therefore, the first relocation is for variable "a", and
    the second relocation is for variable "b".

Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 354954
@tim-pugh
Copy link
Member

tim-pugh commented Mar 7, 2019

I've got our file hooked into the test suite correctly from what I can tell.

The instructions in the google drive are updated to reflect a fix I needed to add (we need to set it to run the test suite in DEBUG mode), and I dropped our POC file into the correct spot. Running the test picks up our POC file, and show's it failing, which I purposely set to do just to save time not collecting the correct output.

So, to finish off this task:

We need to pass the randstruct-seed= into the test-suite, which I believe we do in the cmake command, and recording the correct output.

These should hopefully be easier to solve.

@tim-pugh
Copy link
Member

tim-pugh commented Mar 7, 2019

test-file

@tim-pugh
Copy link
Member

tim-pugh commented Mar 7, 2019

Above is the output from running the test suite with our fork of llvm with randstruct implemented

@tim-pugh
Copy link
Member

tim-pugh commented Mar 8, 2019

I explored some other tests but havne't found much in the way of passing our seed.

Emailing a dev will likely be useful here.

connorkuehl pushed a commit that referenced this issue Mar 8, 2019
Introduces memory leak in FunctionTest.GetPointerAlignment that breaks sanitizer buildbots:

```
=================================================================
==2453==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
    llvm#1 0x16936bc in llvm::User::operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/User.cpp:151:19
    #2 0x7c3fe9 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:12
    #3 0x7c3fe9 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
    #4 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #5 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    #6 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    #7 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    #8 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    #9 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #10 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    #11 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    #12 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    #13 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
    llvm#1 0x151be6b in make_unique<llvm::ValueSymbolTable> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1349:29
    #2 0x151be6b in llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, unsigned int, llvm::Twine const&, llvm::Module*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/Function.cpp:241
    #3 0x7c4006 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:16
    #4 0x7c4006 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
    #5 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #6 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    #7 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    #8 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    #9 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    #10 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #11 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    #12 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    #13 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    #14 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

SUMMARY: AddressSanitizer: 168 byte(s) leaked in 2 allocation(s).
```

See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11358/steps/check-llvm%20asan/logs/stdio for more information.

Also introduces use-of-uninitialized-value in ConstantsTest.FoldGlobalVariablePtr:
```
==7070==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14e703c in User /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5
    llvm#1 0x14e703c in Constant /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/Constant.h:44
    #2 0x14e703c in llvm::GlobalValue::GlobalValue(llvm::Type*, llvm::Value::ValueTy, llvm::Use*, unsigned int, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalValue.h:78
    #3 0x14e5467 in GlobalObject /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalObject.h:34:9
    #4 0x14e5467 in llvm::GlobalVariable::GlobalVariable(llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, llvm::Twine const&, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/Globals.cpp:314
    #5 0x6938f1 in llvm::(anonymous namespace)::ConstantsTest_FoldGlobalVariablePtr_Test::TestBody() /b/sanitizer-x86_64-linux-fast/build/llvm/unittests/IR/ConstantsTest.cpp:565:18
    #6 0x1a240a1 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
    #7 0x1a240a1 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    #8 0x1a26d26 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    #9 0x1a2815f in testing::TestCase::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    #10 0x1a43de8 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    #11 0x1a42c47 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
    #12 0x1a42c47 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    #13 0x1a0dfba in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    #14 0x1a0dfba in main /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    #15 0x7f2081c412e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #16 0x4dff49 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/unittests/IR/IRTests+0x4dff49)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 in User
```

See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30222/steps/check-llvm%20msan/logs/stdio for more information.

llvm-svn: 355616
@tim-pugh
Copy link
Member

Re-assigning to @Nixoncole @jeffreytakahashi @nforbus

What remains to be done:

-pass the seed to the test

-create a test where the same exact struct is randomized and NOT randomized. Compare these structs. If they differ ,good, test is done and return PASS

-create a second test where it also randomizes with the same struct, with the same seed, and compare to the previous tests randomized struct.

if they are the same, good, test is done and return PASS.

connorkuehl pushed a commit that referenced this issue Jul 6, 2019
The arbitrary timeout when flushing GDB remote packets caused
non-determinism and flakiness between test runs. I suspect it is what's
causing the flakiness of the reproducer tests on GreenDragon, and want
to see if removing it causes that to go away.

This change was originally introduced in r197579 to discard a
`$T02thread:01;#4` that QEMU was sending. If anybody knows how to test
that this continues working after removing this code, I'd love to hear
it.

llvm-svn: 364669
connorkuehl pushed a commit that referenced this issue Jul 6, 2019
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 llvm#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 llvm#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

llvm-svn: 364773
connorkuehl pushed a commit that referenced this issue Jul 27, 2019
…s Sunday. Add accessors 'c_encoding' and 'iso_encoding' to provide different interpretations of the weekday. Remove 'operator unsigned'

llvm-svn: 366981
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants