[Buildroot] uClibc debug symbols

[Buildroot] uClibc debug symbols

[Luca Ellero]

Hi everybody,
I'm trying to debug uClibc with a debugger, but even if I enable "build 
packages with debugging symbols" it seems that debug symbols are not 
present in the final binaries.

My .config reports:
BR2_ENABLE_DEBUG=y
BR2_DEBUG_2=y

I'm using binaries in output/staging/lib (is this the correct place to go?)

If I do "objdump -h | grep debug" on this libraries I get the following:

$ arm-buildroot-linux-uclibcgnueabi-objdump -h ld-uClibc-1.0.12.so | 
grep debug

$ arm-buildroot-linux-uclibcgnueabi-objdump -h libuClibc-1.0.12.so | 
grep debug
   20 .debug_aranges 00000180  00000000  00000000  0004b310  2**3
   21 .debug_info   00000c7a  00000000  00000000  0004b490  2**0
   22 .debug_abbrev 00000353  00000000  00000000  0004c10a  2**0
   23 .debug_line   000008ce  00000000  00000000  0004c45d  2**0
   24 .debug_frame  00000124  00000000  00000000  0004cd2c  2**2
   25 .debug_str    00000330  00000000  00000000  0004ce50  2**0
   26 .debug_loc    0000068c  00000000  00000000  0004d180  2**0
   27 .debug_ranges 00000038  00000000  00000000  0004d80c  2**0

Could someone please tell me what is wrong with this approach?

Thanks
Regards
Luca

[Buildroot] uClibc debug symbols

[Peter Seiderer]

Hello Luca,

On Wed, 11 May 2016 11:43:12 +0200, Luca Ellero <luca.ellero@brickedbrain.com> wrote:

> Hi everybody,
> I'm trying to debug uClibc with a debugger, but even if I enable "build 
> packages with debugging symbols" it seems that debug symbols are not 
> present in the final binaries.
> 
> My .config reports:
> BR2_ENABLE_DEBUG=y
> BR2_DEBUG_2=y
> 
> I'm using binaries in output/staging/lib (is this the correct place to go?)
> 
> If I do "objdump -h | grep debug" on this libraries I get the following:
> 
> $ arm-buildroot-linux-uclibcgnueabi-objdump -h ld-uClibc-1.0.12.so | 
> grep debug
> 
> $ arm-buildroot-linux-uclibcgnueabi-objdump -h libuClibc-1.0.12.so | 
> grep debug
>    20 .debug_aranges 00000180  00000000  00000000  0004b310  2**3
>    21 .debug_info   00000c7a  00000000  00000000  0004b490  2**0
>    22 .debug_abbrev 00000353  00000000  00000000  0004c10a  2**0
>    23 .debug_line   000008ce  00000000  00000000  0004c45d  2**0
>    24 .debug_frame  00000124  00000000  00000000  0004cd2c  2**2
>    25 .debug_str    00000330  00000000  00000000  0004ce50  2**0
>    26 .debug_loc    0000068c  00000000  00000000  0004d180  2**0
>    27 .debug_ranges 00000038  00000000  00000000  0004d80c  2**0
> 
> Could someone please tell me what is wrong with this approach?
> 

For remote debugging this should work, the staging/sysroot libs
should have all debugging information, the libs on the target are
stripped until you enable:

  # BR2_STRIP_strip is not set
  BR2_STRIP_none=y

Worked for me with glibc/xserver etc. for local debugging on the
target, not tested with uClibc (do not forget to complete rebuild)...

Regards,
Peter

> Thanks
> Regards
> Luca
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] uClibc debug symbols

[Luca Ellero]

Hi Peter,
thanks for your reply.
See comment at the end.

On 11/05/2016 23:33, Peter Seiderer wrote:
> Hello Luca,
>
> On Wed, 11 May 2016 11:43:12 +0200, Luca Ellero <luca.ellero@brickedbrain.com> wrote:
>
>> Hi everybody,
>> I'm trying to debug uClibc with a debugger, but even if I enable "build
>> packages with debugging symbols" it seems that debug symbols are not
>> present in the final binaries.
>>
>> My .config reports:
>> BR2_ENABLE_DEBUG=y
>> BR2_DEBUG_2=y
>>
>> I'm using binaries in output/staging/lib (is this the correct place to go?)
>>
>> If I do "objdump -h | grep debug" on this libraries I get the following:
>>
>> $ arm-buildroot-linux-uclibcgnueabi-objdump -h ld-uClibc-1.0.12.so |
>> grep debug
>>
>> $ arm-buildroot-linux-uclibcgnueabi-objdump -h libuClibc-1.0.12.so |
>> grep debug
>>    20 .debug_aranges 00000180  00000000  00000000  0004b310  2**3
>>    21 .debug_info   00000c7a  00000000  00000000  0004b490  2**0
>>    22 .debug_abbrev 00000353  00000000  00000000  0004c10a  2**0
>>    23 .debug_line   000008ce  00000000  00000000  0004c45d  2**0
>>    24 .debug_frame  00000124  00000000  00000000  0004cd2c  2**2
>>    25 .debug_str    00000330  00000000  00000000  0004ce50  2**0
>>    26 .debug_loc    0000068c  00000000  00000000  0004d180  2**0
>>    27 .debug_ranges 00000038  00000000  00000000  0004d80c  2**0
>>
>> Could someone please tell me what is wrong with this approach?
>>
>
> For remote debugging this should work, the staging/sysroot libs
> should have all debugging information, the libs on the target are
> stripped until you enable:
>
>   # BR2_STRIP_strip is not set
>   BR2_STRIP_none=y
>
> Worked for me with glibc/xserver etc. for local debugging on the
> target, not tested with uClibc (do not forget to complete rebuild)...
>

I managed to get uClibc with debug symbols using a "dirty hack".

I've added "DODEBUG=y" at the end of file:
~/buildroot-2016.02/package/uclibc/uClibc-ng.config

Anyway I think this is not the right solution.

Doing a "grep BR2_ENABLE_DEBUG" on Buildroot dir I can see that only few 
packages are using BR2_ENABLE_DEBUG.
In particular in "buildroot-2016.02/package/glibc/glibc.mk" (that you 
are referring) there is this code:

ifeq ($(BR2_ENABLE_DEBUG),y)
GLIBC_EXTRA_CFLAGS += -g
endif

But I cannot find anything similar in UClibc.

So my questions are:
- what is the clean way to enable debug symbols on all packages (or at 
least on some of them)?
- what is the purpose of BR2_ENABLE_DEBUG if it doesn't enable debug on 
all packages?


Thanks
Regards
Luca

[Buildroot] uClibc debug symbols

[Thomas Petazzoni]

Hello,

On Thu, 12 May 2016 12:23:52 +0200, Luca Ellero wrote:

> ifeq ($(BR2_ENABLE_DEBUG),y)
> GLIBC_EXTRA_CFLAGS += -g
> endif
> 
> But I cannot find anything similar in UClibc.

Right, we should add explicit handling for BR2_ENABLE_DEBUG in the
uClibc package.

> So my questions are:
> - what is the clean way to enable debug symbols on all packages (or at 
> least on some of them)?

Enabling BR2_ENABLE_DEBUG, as you did.

> - what is the purpose of BR2_ENABLE_DEBUG if it doesn't enable debug on 
> all packages?

The main thing that BR2_ENABLE_DEBUG does is to enable the following
piece of code from package/Makefile.in:

ifeq ($(BR2_DEBUG_1),y)
TARGET_DEBUGGING = -g1
endif
ifeq ($(BR2_DEBUG_2),y)
TARGET_DEBUGGING = -g2
endif
ifeq ($(BR2_DEBUG_3),y)
TARGET_DEBUGGING = -g3
endif

[...]

TARGET_CFLAGS = $(TARGET_CPPFLAGS) $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
TARGET_CXXFLAGS = $(TARGET_CFLAGS)

So TARGET_CFLAGS and TARGET_CXXFLAGS will contain -g1, -g2 or -g3
depending on the debugging "level" requested.

Then, it all depends on each package whether it properly observes
TARGET_CFLAGS/TARGET_CXXFLAGS. I think most autotools-based packages
should behave fine, and all CMake-based packages should also behave
fine.

However, for other packages (mainly the ones that use the
generic-package infrastructure), it is very possible that they don't
pass TARGET_CFLAGS/TARGET_CXXFLAGS everywhere.

Actually, a very useful check to add at the end of the Buidroot build
would be to verify that all binaries have debugging symbols in
STAGING_DIR when BR2_ENABLE_DEBUG=y. This way, the autobuilders would
automatically catch packages that don't behave properly. Adding this
check is probably easy. Fixing the issues that will be found by this
check might prove to be more difficult, however.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] uClibc debug symbols

[Luca Ellero]

Hi Thomas,
thank you for your detailed reply.

On 12/05/2016 15:41, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 12 May 2016 12:23:52 +0200, Luca Ellero wrote:
>
>> ifeq ($(BR2_ENABLE_DEBUG),y)
>> GLIBC_EXTRA_CFLAGS += -g
>> endif
>>
>> But I cannot find anything similar in UClibc.
>
> Right, we should add explicit handling for BR2_ENABLE_DEBUG in the
> uClibc package.
>
>> So my questions are:
>> - what is the clean way to enable debug symbols on all packages (or at
>> least on some of them)?
>
> Enabling BR2_ENABLE_DEBUG, as you did.
>
>> - what is the purpose of BR2_ENABLE_DEBUG if it doesn't enable debug on
>> all packages?
>
> The main thing that BR2_ENABLE_DEBUG does is to enable the following
> piece of code from package/Makefile.in:
>
> ifeq ($(BR2_DEBUG_1),y)
> TARGET_DEBUGGING = -g1
> endif
> ifeq ($(BR2_DEBUG_2),y)
> TARGET_DEBUGGING = -g2
> endif
> ifeq ($(BR2_DEBUG_3),y)
> TARGET_DEBUGGING = -g3
> endif
>
> [...]
>
> TARGET_CFLAGS = $(TARGET_CPPFLAGS) $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
> TARGET_CXXFLAGS = $(TARGET_CFLAGS)
>
> So TARGET_CFLAGS and TARGET_CXXFLAGS will contain -g1, -g2 or -g3
> depending on the debugging "level" requested.
>
> Then, it all depends on each package whether it properly observes
> TARGET_CFLAGS/TARGET_CXXFLAGS. I think most autotools-based packages
> should behave fine, and all CMake-based packages should also behave
> fine.
>
> However, for other packages (mainly the ones that use the
> generic-package infrastructure), it is very possible that they don't
> pass TARGET_CFLAGS/TARGET_CXXFLAGS everywhere.
>
> Actually, a very useful check to add at the end of the Buidroot build
> would be to verify that all binaries have debugging symbols in
> STAGING_DIR when BR2_ENABLE_DEBUG=y. This way, the autobuilders would
> automatically catch packages that don't behave properly. Adding this
> check is probably easy. Fixing the issues that will be found by this
> check might prove to be more difficult, however.

Can you please suggest a way to check whether binaries have debugging 
symbols? So, maybe, we can send patches.

I've tried:
objdump -h ... | grep debug
but it doesn't seem to always behave reliably.

Thank you

Best regards
Luca Ellero

[Buildroot] uClibc debug symbols

[Waldemar Brodkorb]

Hi,
Luca Ellero wrote,

> Can you please suggest a way to check whether binaries have debugging
> symbols? So, maybe, we can send patches.
> 
> I've tried:
> objdump -h ... | grep debug
> but it doesn't seem to always behave reliably.
> 
> Thank you

Just 'file' should do the job,
 best regards
  Waldemar

[Buildroot] uClibc debug symbols

[Luca Ellero]

Hi Waldemar,

On 12/05/2016 19:07, Waldemar Brodkorb wrote:
> Hi,
> Luca Ellero wrote,
>
>> Can you please suggest a way to check whether binaries have debugging
>> symbols? So, maybe, we can send patches.
>>
>> I've tried:
>> objdump -h ... | grep debug
>> but it doesn't seem to always behave reliably.
>>
>> Thank you
>
> Just 'file' should do the job,

file doesn't seem to indicate debug symbols (at least on my system).
Compiling with or without -g has exactly the same output.

$ arm-buildroot-linux-uclibcgnueabi-gcc -o myapp myapp.c
$ file myapp
myapp: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), 
dynamically linked (uses shared libs), not stripped
$ arm-buildroot-linux-uclibcgnueabi-gcc -g -o myapp myapp.c
$ file myapp
myapp: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), 
dynamically linked (uses shared libs), not stripped

Regards

[Buildroot] uClibc debug symbols

[Arnout Vandecappelle]

On 05/13/16 10:34, Luca Ellero wrote:
> Hi Waldemar,
>
> On 12/05/2016 19:07, Waldemar Brodkorb wrote:
>> Hi,
>> Luca Ellero wrote,
>>
>>> Can you please suggest a way to check whether binaries have debugging
>>> symbols? So, maybe, we can send patches.
>>>
>>> I've tried:
>>> objdump -h ... | grep debug
>>> but it doesn't seem to always behave reliably.
>>>
>>> Thank you
>>
>> Just 'file' should do the job,
>
> file doesn't seem to indicate debug symbols (at least on my system).
> Compiling with or without -g has exactly the same output.
>
> $ arm-buildroot-linux-uclibcgnueabi-gcc -o myapp myapp.c
> $ file myapp
> myapp: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically
> linked (uses shared libs), not stripped
> $ arm-buildroot-linux-uclibcgnueabi-gcc -g -o myapp myapp.c
> $ file myapp
> myapp: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically
> linked (uses shared libs), not stripped

  Non-debug binaries still contain the symbol table. The symbol table is 
something that can only be stripped after linking, so it can't be manipulated 
with a compiler option.

  To detect -g, you can do

readelf -S <program> | grep '^ *\[[0-9]*\] \.debug'


  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] uClibc debug symbols

[Luca Ellero]

Hi Arnout,

On 05/14/2016 22:41, Arnout Vandecappelle wrote:
> On 05/13/16 10:34, Luca Ellero wrote:
>> Hi Waldemar,
>>
>> On 12/05/2016 19:07, Waldemar Brodkorb wrote:
>>> Hi,
>>> Luca Ellero wrote,
>>>
>>>> Can you please suggest a way to check whether binaries have debugging
>>>> symbols? So, maybe, we can send patches.
>>>>
>>>> I've tried:
>>>> objdump -h ... | grep debug
>>>> but it doesn't seem to always behave reliably.
>>>>
>>>> Thank you
>>>
>>> Just 'file' should do the job,
>>
>> file doesn't seem to indicate debug symbols (at least on my system).
>> Compiling with or without -g has exactly the same output.
>>
>> $ arm-buildroot-linux-uclibcgnueabi-gcc -o myapp myapp.c
>> $ file myapp
>> myapp: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV),
>> dynamically
>> linked (uses shared libs), not stripped
>> $ arm-buildroot-linux-uclibcgnueabi-gcc -g -o myapp myapp.c
>> $ file myapp
>> myapp: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV),
>> dynamically
>> linked (uses shared libs), not stripped
>
>  Non-debug binaries still contain the symbol table. The symbol table is
> something that can only be stripped after linking, so it can't be
> manipulated with a compiler option.
>
>  To detect -g, you can do
>
> readelf -S <program> | grep '^ *\[[0-9]*\] \.debug'
>
>

Thanks for your reply.
buildroot toolchain creates some debug sections even on non debug binaries.

Here is the output of your suggested method on an example application 
(sorry for the bad formatting):

$ arm-buildroot-linux-uclibcgnueabi-gcc myapp.c -o myapp
$ arm-buildroot-linux-uclibcgnueabi-readelf -S myapp | grep '^ 
*\[[0-9]*\] \.debug'
   [21] .debug_aranges    PROGBITS        00000000 000628 000070 00 
0   0  8
   [22] .debug_info       PROGBITS        00000000 000698 000184 00 
0   0  1
   [23] .debug_abbrev     PROGBITS        00000000 00081c 000038 00 
0   0  1
   [24] .debug_line       PROGBITS        00000000 000854 00011e 00 
0   0  1
   [25] .debug_ranges     PROGBITS        00000000 000978 000040 00 
0   0  8
$ arm-buildroot-linux-uclibcgnueabi-gcc -g myapp.c -o myapp
$ arm-buildroot-linux-uclibcgnueabi-readelf -S myapp | grep '^ 
*\[[0-9]*\] \.debug'
   [21] .debug_aranges    PROGBITS        00000000 000628 000090 00 
0   0  8
   [22] .debug_info       PROGBITS        00000000 0006b8 000213 00 
0   0  1
   [23] .debug_abbrev     PROGBITS        00000000 0008cb 00007c 00 
0   0  1
   [24] .debug_line       PROGBITS        00000000 000947 000156 00 
0   0  1
   [25] .debug_frame      PROGBITS        00000000 000aa0 00002c 00 
0   0  4
   [26] .debug_str        PROGBITS        00000000 000acc 0000d9 01  MS 
0   0  1
   [27] .debug_ranges     PROGBITS        00000000 000ba8 000040 00 
0   0  8

As you can see there are 5 debug section on non debug binary. The 
difference is that there are two section added (.debug_frame and 
.debug_str) compiling with -g.

It is quite difficult to detect debug symbols with this method.

Should we conclude that detecting debug symbols in a reliable way is 
practically impossible?

Regards
Luca

[Buildroot] uClibc debug symbols

[Arnout Vandecappelle]

On 05/17/16 15:32, Luca Ellero wrote:
> Hi Arnout,
>
> On 05/14/2016 22:41, Arnout Vandecappelle wrote:
>> On 05/13/16 10:34, Luca Ellero wrote:
>>> Hi Waldemar,
>>>
>>> On 12/05/2016 19:07, Waldemar Brodkorb wrote:
>>>> Hi,
>>>> Luca Ellero wrote,
>>>>
>>>>> Can you please suggest a way to check whether binaries have debugging
>>>>> symbols? So, maybe, we can send patches.
[snip]
>>  Non-debug binaries still contain the symbol table. The symbol table is
>> something that can only be stripped after linking, so it can't be
>> manipulated with a compiler option.
>>
>>  To detect -g, you can do
>>
>> readelf -S <program> | grep '^ *\[[0-9]*\] \.debug'
>>
>>
>
> Thanks for your reply.
> buildroot toolchain creates some debug sections even on non debug binaries.
>
> Here is the output of your suggested method on an example application (sorry for
> the bad formatting):
>
> $ arm-buildroot-linux-uclibcgnueabi-gcc myapp.c -o myapp
> $ arm-buildroot-linux-uclibcgnueabi-readelf -S myapp | grep '^ *\[[0-9]*\] \.debug'
>   [21] .debug_aranges    PROGBITS        00000000 000628 000070 00 0   0  8
>   [22] .debug_info       PROGBITS        00000000 000698 000184 00 0   0  1
>   [23] .debug_abbrev     PROGBITS        00000000 00081c 000038 00 0   0  1
>   [24] .debug_line       PROGBITS        00000000 000854 00011e 00 0   0  1
>   [25] .debug_ranges     PROGBITS        00000000 000978 000040 00 0   0  8
> $ arm-buildroot-linux-uclibcgnueabi-gcc -g myapp.c -o myapp
> $ arm-buildroot-linux-uclibcgnueabi-readelf -S myapp | grep '^ *\[[0-9]*\] \.debug'
>   [21] .debug_aranges    PROGBITS        00000000 000628 000090 00 0   0  8
>   [22] .debug_info       PROGBITS        00000000 0006b8 000213 00 0   0  1
>   [23] .debug_abbrev     PROGBITS        00000000 0008cb 00007c 00 0   0  1
>   [24] .debug_line       PROGBITS        00000000 000947 000156 00 0   0  1
>   [25] .debug_frame      PROGBITS        00000000 000aa0 00002c 00 0   0  4
>   [26] .debug_str        PROGBITS        00000000 000acc 0000d9 01  MS 0   0  1
>   [27] .debug_ranges     PROGBITS        00000000 000ba8 000040 00 0   0  8
>
> As you can see there are 5 debug section on non debug binary. The difference is
> that there are two section added (.debug_frame and .debug_str) compiling with -g.
>
> It is quite difficult to detect debug symbols with this method.
>
> Should we conclude that detecting debug symbols in a reliable way is practically
> impossible?

  Weird, I didn't see that. But I agree that this proves that there is no 
reliable way to detect presence/absence of debug symbols.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF