[OE-core] gdb failure on simplest hello world program -- oe-selftest

[ChenQi]

On 12/26/2018 07:06 PM, richard.purdie at linuxfoundation.org wrote:
> On Wed, 2018-12-26 at 10:09 +0800, ChenQi wrote:
>> Hi All,
>>
>> 'oe-selftest -r package.PackageTests.test_gdb_hardlink_debug' fails.
>> I did the tests on both my Fedora27 and ubuntu16.04 servers. They both
>> failed.
>> I can also reproduce this issue manually.
>>
>> I did some investigation. No clue how to fix this it. So I want to seek
>> help from community.
>>
>> Below is some output from oe-selftest.
>> [snip]
>> 2018-12-26 09:27:58,440 - oe-selftest - INFO - test_gdb_hardlink_debug
>> (package.PackageTests)
>> 2018-12-26 09:37:55,333 - oe-selftest - INFO - gdbtest /usr/bin/hello1
>> 2018-12-26 09:37:59,904 - oe-selftest - ERROR - GDB result:
>> 1: Reading symbols from /usr/bin/hello1...Reading symbols from
>> /usr/bin/.debug/hello4...done.
>> done.
>> (gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.
>> (gdb) Starting program: /usr/bin/hello1
>>
>> Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
>> 107    /usr/include/bits/stdio2.h: No such file or directory.
>> (gdb) Continuing.
>> Hello World!
>> [Inferior 1 (process 312) exited normally]
>> (gdb)
>> 2018-12-26 09:38:00,907 - oe-selftest - INFO -  ... FAIL
>> [snip]
>>
>> The hello world problem is as follows.
>> $ cat
>> meta-selftest/recipes-test/selftest-hardlink/selftest-hardlink/hello.c
>> #include <stdio.h>
>>
>> int main() {
>>       printf("Hello World!\n");
>> }
>>
>> Some extra information:
>> 1. Remove '-O2' or '-D_FORTIFY_SOURCE=2', and it works correctly.
>> 2. Adding some system call like daemon(0,0) before printf also works.
>> 3. Reverting poky repo to 1c048479af7cc98e30f9a33d1f3bef03711544aa,
>> which adds this selftest case, does not work. It still fails.
>> 4. Hongxu confirms that things work on his host.
>> 5. I also don't see failure about this test case on yocto's autobuilder.
>>
>> Could somebody help to provide some suggestions?
> This is strange and there must be some difference between your
> configuration and what what we test on the autobuilder or on Hongxu's
> setup.

Hi Richard,

I have talked with Hongxu and we can now both confirm that there does 
exist some problem.

> Which DISTRO and MACHINE are you using?

DISTRO is poky
MACHINE is qemux86.

It seems that if MACHINE is qemux86-64, the test case could pass. But 
that's just because the test case only checks 'Breakpoint 1, main () at 
hello.c:4'. See the console output below.
(gdb) b main
*Breakpoint 1 at 0x1050: file /usr/include/bits/stdio2.h, line 107.*
(gdb) r
Starting program: /usr/bin/hello1

*Breakpoint 1, main () at hello.c:4*
4        printf("Hello World!\n");
(gdb) c
Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb) q

Even in this case, the 'b main' does not give correct result. The test 
case passes because 'Breakpoint 1, main () at hello.c:4' is there.

On qemux86, we have:
*(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.*
(gdb) Starting program: /usr/bin/hello1

*Breakpoint 1, main () at /usr/include/bits/stdio2.h:107*
107    /usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb)

> I think the key to resolving this is will be to understanding how to
> reproduce it...

Two ways to reproduce the problem:

I) reproduce it via oe-selftest
1) . oe-init-build-env build-selftest
2) SANITY_TESTED_DISTROS = ""
3) oe-selftest -r package.PackageTests.test_gdb_hardlink_debug

II) reproduce it manually
1) add meta-selftest to bblayers.conf
2) IMAGE_INSTALL_append = " selftest-hardlink selftest-hardlink-dbg 
selftest-hardlink-gdb"
3) bitbake core-image-minimal
4) On target:
      gdb /usr/bin/hello1
      (gdb) b main

Best Regards,
Chen Qi

> I think its worth investigating and figuring out...
>
> Cheers,
>
> Richard
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20181228/bff3b9de/attachment.html>