gdb, values optimized out with binaries compiled from Asan

[Jonathan]

Hello,

I was wondering if I use a binary compiled with Asan and without
optimization (no -O? flags) should I not be able to see variables
content in gdb (i.e. 'info args' after breaking into a function)
instead of getting the "value optimized out" ?

The context is on a Linux system with C code and the trunk Asan.

Regards,

jonathan

[Konstantin Serebryany]

I would expect that "clang -g -faddress-sanitizer" (w/o -O[123]) should produce a binary equally debuggable as "clang -g" would produce. 

We often use gdb on asan-built binarie, but most frequently we build with -O[12] and there are some problems with debugability. 

I've just tried a simplest possible experiment with clang (which I've just build from trunk) and I see a problem (even w/o asan):

----------------------------------------------------------------------------------

% cat main.c

int main(int argc, char *argv[]) {

  return argv[0][0];

}

% clang -g  main.c && gdb a.out 

Reading symbols from /home/kcc/tmp/a.out...done.

(gdb) b main

Breakpoint 1 at 0x4004d0: file main.c, line 1.

(gdb) r

Starting program: /home/kcc/tmp/a.out 

Breakpoint 1, main (argc=0, argv=0x0) at main.c:1

1       int main(int argc, char *argv[]) {

----------------------------------------------------------------------------------

The values of argc/argv are not seen by the debugger. 

This sounds like clang/llvm problem. Would you mind reporting it to llv...@cs.uiuc.edu? 

(Or I can do it too). 

Thanks for the report. 

--kcc

[Jonathan]

On 19 jan, 22:24, Konstantin Serebryany

<konstantin.s.serebry...@gmail.com> wrote:
> I would expect that "clang -g -faddress-sanitizer" (w/o -O[123]) should
> produce a binary equally debuggable as "clang -g" would produce.
> We often use gdb on asan-built binarie, but most frequently we build with
> -O[12] and there are some problems with debugability.
>
> I've just tried a simplest possible experiment with clang (which I've just
> build from trunk) and I see a problem (even w/o asan):
>
> ----------------------------------------------------------------------------------
> % cat main.c
> int main(int argc, char *argv[]) {
>   return argv[0][0];}
>
> % clang -g  main.c && gdb a.out
> Reading symbols from /home/kcc/tmp/a.out...done.
> (gdb) b main
> Breakpoint 1 at 0x4004d0: file main.c, line 1.
> (gdb) r
> Starting program: /home/kcc/tmp/a.out
>
> Breakpoint 1, main (argc=0, argv=0x0) at main.c:1
> 1       int main(int argc, char *argv[]) {
> ----------------------------------------------------------------------------------
>
> The values of argc/argv are not seen by the debugger.
> This sounds like clang/llvm problem. Would you mind reporting it to

> llvm...@cs.uiuc.edu?

> (Or I can do it too).
>
> Thanks for the report.
> --kcc
>

On my side I've made this test :

----------------------------------------------------------
› cat
test_debug.c
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <string.h>

int function2(char *text)
{
int ret = -1;

if (0 == strlen(text))
ret = 512;
else
ret = 8;

return ret;
}

static bool function1(int count, char *text)
{
bool status = true;

if (-1 == function2(text))
status = false;

printf("[%d] - '%s'\n", count, text);

return status;
}

int main(int argc, char const *argv[])
{
printf("start\n");

if (!function1(5, "test1"))
printf("error\n");

if (!function1(1, ""))
printf("error\n");

printf("end\n");
return 0;
}
----------------------------------------------------------

When I compile it using clang only, I get in gdb :

----------------------------------------------------------
› gdb ./a.out -batch -x
batch_gdb
$1 = "Inserting breakpoint... "
Breakpoint 1 at 0x40054c: file test_debug.c, line 8.
$2 = "Launching program... "
start

Breakpoint 1, function2 (text=0x400793 "test1") at test_debug.c:8
8 int ret = -1;
$3 = "Content of char *text in function2()... "
$4 = 0x400793 "test1"
$5 = "Going up into function1()... "
#1 0x000000000040065c in function1 (count=5, text=0x400793 "test1")
at test_debug.c:22
22 if (-1 == function2(text))
$6 = "[-] info locals in function1()... "
status = true
$7 = "[-] info args in function1()... "
count = 5
text = 0x400793 "test1"
[5] - 'test1'
[1] - ''
end
[Inferior 1 (process 4416) exited normally]
----------------------------------------------------------

but when compiling it with Address-Sanitizer I get :

----------------------------------------------------------
› gdb ./a.out -batch -x
batch_gdb
$1 = "Inserting breakpoint... "
Breakpoint 1 at 0x404f1b: file test_debug.c, line 8.
$2 = "Launching program... "
[Thread debugging using libthread_db enabled]
start

Breakpoint 1, function2 (text=0x7fffffffe2a0 "\340\363@") at
test_debug.c:8
8 int ret = -1;
$3 = "Content of char *text in function2()... "
$4 = 0x7fffffffe2a0 "\340\363@"
$5 = "Going up into function1()... "
#1 0x0000000000405522 in function1 (count=<optimized out>,
text=<optimized out>) at test_debug.c:22
22 if (-1 == function2(text))
$6 = "[-] info locals in function1()... "
status = 128
$7 = "[-] info args in function1()... "
count = <optimized out>
text = <optimized out>
[5] - 'test1'
[1] - ''
end
[Inferior 1 (process 10957) exited normally]
----------------------------------------------------------


› clang --
version
clang version 3.1 (trunk 148535)
Target: x86_64-unknown-linux-gnu
Thread model: posix

› cat batch_gdb
print "Inserting breakpoint... "
break function2
print "Launching program... "
run
print "Content of char *text in function2()... "
print text
print "Going up into function1()... "
up
print "[-] info locals in function1()... "
info locals
print "[-] info args in function1()... "
info args
delete 1
continue
quit

Should I post the problem on llvm-dev@ ,or enter a new bug in the
bugtracker ?


-- jonathan

[Konstantin Serebryany]

Jonathan, 

I can reproduce this problem. 

Yes, please file a bug to the LLVM bug tracker. http://llvm.org/bugs/

Even though on this example debug info is broken only with -faddress-sanitizer, I don't think this is an asan-specific issue. 

Thanks, 

--kcc

[Jonathan]

On 20 jan, 19:23, Konstantin Serebryany

<konstantin.s.serebry...@gmail.com> wrote:
> Jonathan,
>
> I can reproduce this problem.

> Yes, please file a bug to the LLVM bug tracker.http://llvm.org/bugs/

> Even though on this example debug info is broken only with
> -faddress-sanitizer, I don't think this is an asan-specific issue.
>
> Thanks,
> --kcc
>

For reference, the bug filed in LLVM bugtracker : #ID : 11818

It's seems that the DWARF output is wrong when compiled with Address-
Sanitizer.

jonathan

[Jonathan]

On 27 jan, 23:19, Jonathan <mkvtoolnix.build.jon...@gmail.com> wrote:
>
> For reference, the bug filed in LLVM bugtracker : #ID : 11818
>
> It's seems that the DWARF output is wrong when compiled with Address-
> Sanitizer.
>
>  jonathan

I was thinking that may be there is a 'typical' offset shift for the
variable's address
so I wrote this little code below :

› cat
test_simple.c
#include <stdio.h>
#include <inttypes.h>

int main(int argc, char *argv[])
{

char local_s[] = "Simple string";

printf("%s\n", local_s);
printf("type in gdb : \n");
printf("\t(for local_s....)\n");
printf("x/s %#"PRIxPTR"\n", (uintptr_t) local_s);
printf("p/x local_s - %#"PRIxPTR"\n", (uintptr_t) local_s);

__builtin_trap();

return 0;
}

› clang -g test_simple.c
› gdb ./
a.out
GNU gdb (GDB) 7.3.1
gdb$ r
Simple string
type in gdb :
(for local_s....)
x/s 0x7fffffffe702
p/x local_s - 0x7fffffffe702

Program received signal SIGILL, Illegal instruction.
main (argc=1, argv=0x7fffffffe808) at test_simple.c:15
15 __builtin_trap();
gdb$ p/x local_s - 0x7fffffffe702
$1 = 0x0
gdb$ quit

› clang -g -faddress-sanitizer test_simple.c
› gdb ./
a.out
GNU gdb (GDB) 7.3.1
gdb$ r

[Thread debugging using libthread_db enabled]

Simple string
type in gdb :
(for local_s....)
x/s 0x7fffffffe6c0
p/x local_s - 0x7fffffffe6c0

Program received signal SIGILL, Illegal instruction.
main (argc=<optimized out>, argv=<optimized out>) at test_simple.c:15
15 __builtin_trap();
gdb$ p/x local_s - 0x7fffffffe6c0
$1 = 0xfffffffffffffef0
gdb$ p/d local_s - 0x7fffffffe6c0
$2 = -272
gdb$ quit

but if I had some variables before 'local_s'
----
int a, b ,c;
char toto[40];
----

I get :

gdb$ r

[Thread debugging using libthread_db enabled]

Simple string
type in gdb :
(for local_s....)
x/s 0x7fffffffe6c0
p/x local_s - 0x7fffffffe6c0

Program received signal SIGILL, Illegal instruction.
main (argc=<optimized out>, argv=<optimized out>) at test_simple.c:17
17 __builtin_trap();
gdb$ p/x local_s - 0x7fffffffe6c0
$1 = 0xfffffffffffffd90
gdb$ p/d local_s - 0x7fffffffe6c0
$2 = -624
gdb$ quit

I don't know if it's any help.

[Alexey Samsonov]

Thanks for the repro!

This reminds me of http://code.google.com/p/address-sanitizer/issues/detail?id=13 and upstream bug http://llvm.org/bugs/show_bug.cgi?id=11468

My guess is that Clang produces incorrect DWARF output if rsp is aligned (we explicitly add such alignment during AddressSanitizer pass).

--

Alexey Samsonov

Software Engineer, Moscow

sams...@google.com

[Christian Eltges]

Hi,

I use clang+llvm 3.1 and still see this problem, the debug infos are not usable (most variables optimized out) when I compile with -faddress-sanitizer, otherwise they are ok.

The same with latest clang+llvm from the repo.

As this discussion is from january, I wonder if there is any progress.

Best regards

Christian

[Konstantin Serebryany]

On Tue, Oct 30, 2012 at 4:11 PM, Christian Eltges <elt...@gmail.com> wrote:

Hi,

I use clang+llvm 3.1 and still see this problem, the debug infos are not usable (most variables optimized out) when I compile with -faddress-sanitizer, otherwise they are ok.

The same with latest clang+llvm from the repo.

As this discussion is from january, I wonder if there is any progress.

Unfortunately, there is no progress, sorry.

http://code.google.com/p/address-sanitizer/issues/detail?id=41

This is hurting us too, so there is a chance to have this fixed in a few months, but no promises. 

--kcc