Yocto Dunfell: package.class --> dwarfsrcfiles

Yocto Dunfell: package.class --> dwarfsrcfiles

[jhannig]

[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]

Hello,



with the upgrade from Yocto Zeus → Dunfell, we observe lots of messages when building our product which seem heavy to be understood or to debug.

Actually, it's the failure of the "do_package" task of a proprietary module written in C with following message:



ERROR: eds-1.0-r0 do_package: dwarfsrcfiles failed with exit code 1 (cmd was ['dwarfsrcfiles', '/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a']):

dwarfsrcfiles: /home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a: not a valid ELF file



ERROR: Logfile of failure stored in: /home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/temp/log.do_package.13957

ERROR: Task (/home/jhannig/workspace/mguard/meta-mguard/recipes-core/eds/eds_1.0.bb:do_package) failed with exit code '1'



Following information to understand the problem:

- The code of this module wasn't changed, and it compiled errorless with release "Zeus"

- The examination of the file "libhdb.a" brings following results:

- It is possible to unpack the archive-file "libhdb.a":  jhannig@jhannig:~/Archiv/MG-2436$ ar x libhdb.a

- The Examination of the content with "file *.o" [jhannig@jhannig:~/Archiv/MG-2436$ file *.o] brings following results:

hdb.o:             ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped

hdbschema.o:       ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped

hdbstaticschema.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped

utils.o:           ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped

- This corresponds with the expectation and the intended character of the file

- Minor changes in the makefile command line didn't change anything in the result [EXTRA_OEMAKE += 'CC="${CC}" CPPFLAGS="${CPPFLAGS}" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" AR="${AR}" EDS_XML="${EDS_XML}"']

- Searching the internet for "dwarfsrcfiles" doesn't bring any informative or documentative result, so it doesn't become clear, what this tool exactly does.



Following questions asked to the community:

- Which cases of errors result in this error message?

- What changed with the new yocto release, that "suddenly" a build result is analyzed as failure?

- Where exactly in the tool code is this error thrown? The message "not a valid ELF file" isn't available in the code

- What should be done with the archive file and its content to eliminate the error?

- Is this behavior well known, and is there any documentation to get information about the tool?



Thanks a lot for help,

kind regards



Jan Hannig

Reasearch and Development



jhannig@phoenixcontact.com<mailto:jhannig@phoenixcontact.com>

www.phoenixcontact.com<http://www.phoenixcontact.com>





.......................................................................................
PHOENIX CONTACT Cyber Security GmbH 
Richard-Willstätter-Straße 6  
D-12489 Berlin  
 
Register Court: AG Charlottenburg, HR B 202908 
Geschäftsführer/General Manager: Kilian Golm

[-- Attachment #2: Type: text/html, Size: 8905 bytes --]

Re: [yocto] Yocto Dunfell: package.class --> dwarfsrcfiles

[Khem Raj]

On 7/21/20 3:45 AM, Jan Hannig wrote:
> Hello,
> 
> with the upgrade from Yocto Zeus → Dunfell, we observe lots of messages 
> when building our product which seem heavy to be understood or to debug.
> 
> Actually, it's the failure of the "do_package" task of a proprietary 
> module written in C with following message:
> 
> ERROR: eds-1.0-r0 do_package: dwarfsrcfiles failed with exit code 1 (cmd 
> was ['dwarfsrcfiles', 
> '/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a']):
> 
> dwarfsrcfiles: 
> /home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a: 
> not a valid ELF file
> 
> ERROR: Logfile of failure stored in: 
> /home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/temp/log.do_package.13957
> 
> ERROR: Task 
> (/home/jhannig/workspace/mguard/meta-mguard/recipes-core/eds/eds_1.0.bb:do_package) 
> failed with exit code '1'
> 
> Following information to understand the problem:
> 
> - The code of this module wasn't changed, and it compiled errorless with 
> release "Zeus"
> 
> - The examination of the file "libhdb.a" brings following results:
> 
> - It is possible to unpack the archive-file "libhdb.a": 
>   jhannig@jhannig:~/Archiv/MG-2436$ ar x libhdb.a
> 
> - The Examination of the content with "file *.o" 
> [jhannig@jhannig:~/Archiv/MG-2436$ file *.o] brings following results:
> 
> hdb.o:             ELF 64-bit LSB relocatable, ARM aarch64, version 1 
> (SYSV), not stripped
> 
> hdbschema.o:       ELF 64-bit LSB relocatable, ARM aarch64, version 1 
> (SYSV), not stripped
> 
> hdbstaticschema.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 
> (SYSV), not stripped
> 
> utils.o:           ELF 64-bit LSB relocatable, ARM aarch64, version 1 
> (SYSV), not stripped
> 
> - This corresponds with the expectation and the intended character of 
> the file
> 
> - Minor changes in the makefile command line didn't change anything in 
> the result [EXTRA_OEMAKE += 'CC="${CC}" CPPFLAGS="${CPPFLAGS}" 
> CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" AR="${AR}" EDS_XML="${EDS_XML}"']
> 
> - Searching the internet for "dwarfsrcfiles" doesn't bring any 
> informative or documentative result, so it doesn't become clear, what 
> this tool exactly does.
> 
> Following questions asked to the community:
> 
> - Which cases of errors result in this error message?

something goes amiss in the ELF object generation, it could be many 
reasons like corrupt files or additional information in these objects 
which can confuse the dwarf reader

> 
> - What changed with the new yocto release, that "suddenly" a build 
> result is analyzed as failure?

packages get upgraded and in this particular case elfutils is the main 
package and it would have got upgraded to new revision which can bring 
additional behavior.

> 
> - Where exactly in the tool code is this error thrown? The message "not 
> a valid ELF file" isn't available in the code


its coming from dwarf reader provided by libdwfl from elfutils package.

> 
> - What should be done with the archive file and its content to eliminate 
> the error?

its not clear as to what might be going here so hard to say, but perhaps 
you can debug dwarfsrcfiles tool using gdb and your .a file as input and 
see why it things its a bad ELF object. It will perhaps give more 
insights. Its a native tool so should be easy to debug through. May be 
share stack trace etc. when it reaches the error state.

Secondly, it will be good to look at the build options used to create 
this .a and see if something stands out.

> 
> - Is this behavior well known, and is there any documentation to get 
> information about the tool?

its not well known, but its an error state that can happen.

> 
> Thanks a lot for help,
> 
> kind regards
> 
> Jan Hannig
> 
> Reasearch and Development
> 
> jhannig@phoenixcontact.com <mailto:jhannig@phoenixcontact.com>
> 
> www.phoenixcontact.com <http://www.phoenixcontact.com>
> 
> .......................................................................................
> 
> PHOENIX CONTACT Cyber Security GmbH　
> 
> Richard-Willstätter-Straße 6 　
> 
> D-12489 Berlin 　
> 
> 　
> 
> Register Court: AG Charlottenburg, HR B 202908　
> 
> Geschäftsführer/General Manager: Kilian Golm
> 
> //
> 
> 
> 

[yocto] Yocto Dunfell: package.class --> dwarfsrcfiles

[Jan Hannig]

Hello, 

thanks for the reply and the useful hints concerning our questions!

After a debug session, it came out, that the *.a archive doesn't contain only *.o files, but also one *.c file.
That was missed during the first analysis.
Interestingly enough, the error came out only with the Dunfell Upgrade.
Deleting the *.c file in the archive corrected the error message.

Jan Hannig
Reasearch and Development
jhannig@phoenixcontact.com
www.phoenixcontact.com



.......................................................................................
PHOENIX CONTACT Cyber Security GmbH 
Richard-Willstätter-Straße 6  
D-12489 Berlin  
 
Register Court: AG Charlottenburg, HR B 202908 
Geschäftsführer/General Manager: Kilian Golm