Bug 1091989

(In reply to Petr Spacek from comment #0)
> Expected results:
> Headers in debuginfo package are the same as for build with -O2.

Why is it needed?  There is no need to guarantee that.  gcc outputs only the minimal set of necessary DWARF content and as -O2 contains more debug info (as it needs to describe more complicated optimized code) it needs to output also more filenames for it.

Here is a reproducer - if 'gcc -O0 -g' and 'gcc -O2 -g' produced the same filenames list one should see both 'O0.wil' and 'O2.wil' lines from grep.  But one does not:
echo >header.h 'void f(void);';for O in 0 2;do echo -e '#include "header.h"\nvoid g(void){f();}'|gcc -o O$O.o -O$O -c -g -Wall -x c -;readelf -wil O$O.o >O$O.wil;done;grep -l header.h O{0,2}.wil
O2.wil

The reason is DW_TAG_GNU_call_site debug information which is produced only with -O2 -g (and not -O0 -g) because such debug info is not needed for debugging of the simple code produced using -O0 -g. Particularly -O0 does not use tail calls and -O0 also does use stack frame memory slots for all variables (and not callee-clobbered registers only like -O2).

readelf -wil O2.o
Contents of the .debug_info section:
 <2><44>: Abbrev Number: 3 (DW_TAG_GNU_call_site)
    <45>   DW_AT_low_pc      : 0x5
    <4d>   DW_AT_GNU_tail_call: 1
    <4d>   DW_AT_abstract_origin: <0x52>
 <1><52>: Abbrev Number: 4 (DW_TAG_subprogram)
    <53>   DW_AT_external    : 1
    <53>   DW_AT_name        : f
    <55>   DW_AT_decl_file   : 2
    <56>   DW_AT_decl_line   : 1
 The File Name Table:
  Entry Dir     Time    Size    Name
  2     0       0       0       header.h

(In reply to Jan Kratochvil from comment #1)
> (In reply to Petr Spacek from comment #0)
> > Expected results:
> > Headers in debuginfo package are the same as for build with -O2.
> Why is it needed?  There is no need to guarantee that.

Right, Expected results can be too strict/poorly formulated. 

Do I understand correctly that debuginfo package should contain all headers necessary for undestanding the compiled code?

In my case, debuginfo package generated with -O0 -g is missing some important headers, e.g. bin/named/include/named/control.h. The code without this header is hard to read because it is missing important #defines, e.g. NS_COMMAND_STOP.

In that case lines like:
} else if (command_compare(command, NS_COMMAND_STOP)) {
doesn't make much sense because you can't see value of NS_COMMAND_STOP.

Debuginfo package is missing 118 out of 283 header files in /usr/src/debug/bind-9.9.4-P2 which seems way too much.

Does it explain my problem?

P.S. Of course, the value is somewhere in the binary code, but isn't the purpose of debuginfo package to make debugging easier? :-)

(In reply to Petr Spacek from comment #2)
> Do I understand correctly that debuginfo package should contain all headers
> necessary for undestanding the compiled code?

IMO *-debuginfo should contain enough sources to understand a crash.
This Bug rather gave me an idea we should drop the header files required only for DW_TAG_GNU_call_site as they needlessly enlarge the *-debuginfo rpms.


> In my case, debuginfo package generated with -O0 -g is missing some
> important headers, e.g. bin/named/include/named/control.h. The code without
> this header is hard to read because it is missing important #defines, e.g.
> NS_COMMAND_STOP.
> 
> In that case lines like:
> } else if (command_compare(command, NS_COMMAND_STOP)) {
> doesn't make much sense because you can't see value of NS_COMMAND_STOP.

It was discussed in:
  Shall we modify '-g' to '-g3' to have gcc save the macro info?
  https://lists.fedoraproject.org/pipermail/devel/2013-January/176313.html
and also shortly in
  https://bugzilla.redhat.com/show_bug.cgi?id=833311
and the conclusion was that macro information is too big vs. its usefulness.
(Personally I think macro info (-g3) would be useful in *-debuginfo rpms.)

With bind-debuginfo.rpm rebuilt using -g3 (even with -O0):

Breakpoint 1, command_compare (text=0x7fffd0000e60 "null", command=0x5555555e08b3 "null") at control.c:48
48              unsigned int commandlen = strlen(command);
(gdb) up
#1  0x00005555555779f5 in ns_control_docommand (message=0x7fffd0000900, text=0x7ffff2405940) at control.c:90
90              if (command_compare(command, NS_COMMAND_NULL) ||
(gdb) p NS_COMMAND_NULL
$1 = "null"
(gdb) info macro NS_COMMAND_NULL
Defined at /usr/src/debug/bind-9.9.4-P2/bin/named/include/named/control.h:59
  included at /usr/src/debug/bind-9.9.4-P2/bin/named/control.c:38
#define NS_COMMAND_NULL "null"
(gdb) _

Standard Fedora bind-debuginfo.rpm:

Breakpoint 1, command_compare (text=0x7fffd0000e60 "null", command=0x5555555d2ff4 "null") at control.c:47
47	command_compare(const char *text, const char *command) {
(gdb) up
#1  0x000055555558156e in ns_control_docommand (message=<optimized out>, text=text@entry=0x7ffff1eb7890)
    at control.c:90
90		if (command_compare(command, NS_COMMAND_NULL) ||
(gdb) p NS_COMMAND_NULL
No symbol "NS_COMMAND_NULL" in current context.
(gdb) info macro NS_COMMAND_NULL
The symbol `NS_COMMAND_NULL' has no definition as a C/C++ preprocessor macro
at <user-defined>:-1
(gdb) _

This Bug should be renamed to "-g3" if you think the macro info is worth the increased Fedora *-debuginfo.rpm size.

I still do not understand how the default "-g -O2" *-debuginfo.rpm is useful for you. If you grep 'NS_COMMAND_NULL' out of /usr/src/debug/bind-9.9.4-P2/ I do not think it is a good enough justification - .src.rpm is IMO more appropriate to use in such case.

> This Bug should be renamed to "-g3" if you think the macro info is worth the
> increased Fedora *-debuginfo.rpm size.
> 
> I still do not understand how the default "-g -O2" *-debuginfo.rpm is useful
> for you. If you grep 'NS_COMMAND_NULL' out of /usr/src/debug/bind-9.9.4-P2/
> I do not think it is a good enough justification - .src.rpm is IMO more
> appropriate to use in such case.

Maybe we don't understand each other.
grep -R 'NS_COMMAND_NULL' /usr/src/debug/bind-9.9.4-P2/
yields nothing if I compile the package with -O0. It is perfectly okay if I use -O2 but is it not okay if I compile it with -O0.

I hope this clears the confusion and I'm sorry for the delay.

(In reply to Petr Spacek from comment #4)
> grep -R 'NS_COMMAND_NULL' /usr/src/debug/bind-9.9.4-P2/
> yields nothing

It is irrelevant what 'grep ... /usr/src/debug/...' yields.
That directory is only for debugging tools like GDB.  Never access it by hand.  If you find it useful by hand fine, if you do not use something else.

Do you have any other concerns about debuginfo?

To make sure I understand you:
Are you saying that I should always download src.rpm and do "rpmbuild -bp" and grep there?

(In reply to Petr Spacek from comment #6)
> Are you saying that I should always download src.rpm and do "rpmbuild -bp"
> and grep there?

Yes.  This is the only way and this is what I have always been doing.