Viewing the address of an array in gdb

Viewing the address of an array in gdb

[Mahmood Naderan via gdb]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 8402 bytes --]

Hi,
I have define "char buffer[100]" in a C code. Trying to view the location of buffer in GDB, I see this


(gdb) p &buffer[0]
$1 = 0x7ffff7dd43e0 <buffer> ""
(gdb) x/30x 0x7ffff7dd43e0
0x7ffff7dd43e0 <buffer>:    0x00000000    0x00000000    0x00000000    0x00000000
0x7ffff7dd43f0 <buffer+16>:    0x00000000    0x00000000    0x00000000    0x00000000
0x7ffff7dd4400 <_dl_open_hook>:    0x00000000    0x00000000    0xffb51dd2    0xa7d1a586
0x7ffff7dd4410 <__vdso_getcpu>:    0xf5b51dd2    0xa7d1a586    0xffffdf28    0x00007fff
0x7ffff7dd4420 <__libc_argc>:    0x00000002    0x00000000    0x00000000    0x00000000
0x7ffff7dd4430 <__gconv_alias_db>:    0x00000000    0x00000000    0x00000000    0x00000000
0x7ffff7dd4440 <__gconv_modules_db>:    0x00000000    0x00000000    0x00000000    0x00000000
0x7ffff7dd4450 <__gconv_path_envvar>:    0x00000000    0x00000000
(gdb) p &buffer[99]
$2 = 0x7ffff7dd4443 <__gconv_modules_db+3> ""
(gdb) 



Why I don't see <buffer+32> and similar things?


Regards,
Mahmood
From gdb-return-46502-listarch-gdb=sources.redhat.com@sourceware.org Fri Jul 06 11:15:40 2018
Return-Path: <gdb-return-46502-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 60353 invoked by alias); 6 Jul 2018 11:15:39 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 60117 invoked by uid 89); 6 Jul 2018 11:15:25 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:PHrt, H*RU:74.6.131.42, H*r:ip*74.6.131.42, Hx-spam-relays-external:74.6.131.42
X-HELO: sonic303-3.consmr.mail.bf2.yahoo.com
Received: from sonic303-3.consmr.mail.bf2.yahoo.com (HELO sonic303-3.consmr.mail.bf2.yahoo.com) (74.6.131.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jul 2018 11:15:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t\x1530875707; bh=+ICGq2jEUtXmsvF9xyTfTeCjwc3DbBVA4zAWywkNJY4=; hÚte:From:Reply-To:To:Subject:References:From:Subject; b=CqCbClKpGFo7/sF4YYcnspeI91Yjnglaie6on8o590BgQ8/qAnEt81GejXTlsMg1RkkTQmJeHguSqBVTv+hXSjD962oTSbEmW+HjN1TdVRoqoXh8fy4Ge62CicKF0bNI5Ldm2YXrVPo8rBAqyZZ7Rj0MwEjZSiBL4siYAIaReh6xV9/lfJYCXIzy2x6qrDahvJhk/0C7vym3gjs8v77XESaxGS9iSxlsUIKI5qjIQVY0MO+u5Dj3t7U5OuR+OUwdvb8xCF2GSQXkafivgVpI3d7us/gyI/Blnqmpj4RQialQwjWWgn8b2Yq59H0Ee1MtQ0/rqUFmasE5+8awpmwxYQ=Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 6 Jul 2018 11:15:07 +0000
Date: Fri, 06 Jul 2018 11:15:00 -0000
From: "Mahmood Naderan via gdb" <gdb@sourceware.org>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
To: "gdb@sourceware.org" <gdb@sourceware.org>
Message-ID: <1839186466.17059.1530875705518@mail.yahoo.com>
Subject: debugging a callq command
MIME-Version: 1.0
References: <1839186466.17059.1530875705518.ref@mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
X-SW-Source: 2018-07/txt/msg00014.txt.bz2
Content-length: 2712

Hi,
Trying to debug an assembly code with gdb, I see that a call function to a valid address exists but the control won't go to the target address.

As you can see, the first instruction is a jmp to 0x7fffffffde7d and there, it will call 0x7fffffffde70. However, the next instruction is something else while the program receives seg fault.

(gdb) nexti
0x00007fffffffde6e in ?? ()
1: x/20i $pc
=> 0x7fffffffde6e:    jmp    0x7fffffffde7d
   0x7fffffffde70:    pop    %rsi
   0x7fffffffde71:    xor    %ecx,%ecx
   0x7fffffffde73:    mov    $0x21,%cl
   0x7fffffffde75:    xorb   $0x35,(%rsi)
   0x7fffffffde78:    rex.RX loop 0x7fffffffde75
   0x7fffffffde7b:    jmp    0x7fffffffde82
   0x7fffffffde7d:    callq  0x7fffffffde70
   0x7fffffffde82:    pop    %rdi
   0x7fffffffde83:    jae    0x7fffffffdef2
(gdb) nexti
0x00007fffffffde6e in ?? ()
1: x/20i $pc
=> 0x7fffffffde6e:    jmp    0x7fffffffde7d
   0x7fffffffde70:    pop    %rsi
   0x7fffffffde71:    xor    %ecx,%ecx
   0x7fffffffde73:    mov    $0x21,%cl
   0x7fffffffde75:    xorb   $0x35,(%rsi)
   0x7fffffffde78:    rex.RX loop 0x7fffffffde75
   0x7fffffffde7b:    jmp    0x7fffffffde82
   0x7fffffffde7d:    callq  0x7fffffffde70
   0x7fffffffde82:    pop    %rdi
   0x7fffffffde83:    jae    0x7fffffffdef2
(gdb) nexti

Program received signal SIGSEGV, Segmentation fault.
0x00007fffffffde8c in ?? ()
1: x/20i $pc
=> 0x7fffffffde8c:    out    %eax,$0x5f
   0x7fffffffde8e:    ds insl (%dx),%es:(%rdi)
   0x7fffffffde90:    addr32 pop %rbp
   0x7fffffffde92:    sbb    0x46(%rdi),%cl
   0x7fffffffde95:    pop    %rbp
   0x7fffffffde96:    pop    %rbp
   0x7fffffffde97:    sbb    0x5c(%rdi),%dl




What is happening there? Any idea?



Regards,
Mahmood
From gdb-return-46503-listarch-gdb=sources.redhat.com@sourceware.org Fri Jul 06 11:31:08 2018
Return-Path: <gdb-return-46503-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 57426 invoked by alias); 6 Jul 2018 11:30:59 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 56158 invoked by uid 89); 6 Jul 2018 11:30:29 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammyºldwin, baldwin, sk:decr_af, sk:decr_pc
X-HELO: mx1.redhat.com
Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jul 2018 11:30:28 +0000
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5])	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id 9AE16E9003;	Fri,  6 Jul 2018 11:30:18 +0000 (UTC)
Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4])	by smtp.corp.redhat.com (Postfix) with ESMTP id 6D9857C21;	Fri,  6 Jul 2018 11:30:17 +0000 (UTC)
Subject: Re: RISC-V: decr_pc_after_break causing problems
To: John Baldwin <jhb@FreeBSD.org>, Palmer Dabbelt <palmer@sifive.com>, Jim Wilson <jimw@sifive.com>, andrew.burgess@embecosm.com
References: <mhng-c2172dd6-d7fb-4df6-87d4-a180afd408e3@palmer-si-x1c4> <95eb8848-182b-dab4-f9dc-298269885f53@FreeBSD.org>
Cc: gdb@sourceware.org
From: Pedro Alves <palves@redhat.com>
Message-ID: <d1125dae-66a2-d347-5017-64917114657c@redhat.com>
Date: Fri, 06 Jul 2018 11:30:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <95eb8848-182b-dab4-f9dc-298269885f53@FreeBSD.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-07/txt/msg00015.txt.bz2
Content-length: 299

On 07/05/2018 11:54 PM, John Baldwin wrote:

> FWIW, my preference would be for the decr_after_pc_break match the hardware
> which from my understanding of the thread means it should always be zero.

Mine too, FWIW.  PC adjustment is a source of trouble in ports that need it.

Thanks,
Pedro Alves

Re: Viewing the address of an array in gdb

[Pedro Alves]

On 07/06/2018 04:33 AM, Mahmood Naderan via gdb wrote:
> Hi,
> I have define "char buffer[100]" in a C code. Trying to view the location of buffer in GDB, I see this
> 
> 
> (gdb) p &buffer[0]
> $1 = 0x7ffff7dd43e0 <buffer> ""
> (gdb) x/30x 0x7ffff7dd43e0
> 0x7ffff7dd43e0 <buffer>:    0x00000000    0x00000000    0x00000000    0x00000000
> 0x7ffff7dd43f0 <buffer+16>:    0x00000000    0x00000000    0x00000000    0x00000000
> 0x7ffff7dd4400 <_dl_open_hook>:    0x00000000    0x00000000    0xffb51dd2    0xa7d1a586
> 0x7ffff7dd4410 <__vdso_getcpu>:    0xf5b51dd2    0xa7d1a586    0xffffdf28    0x00007fff
> 0x7ffff7dd4420 <__libc_argc>:    0x00000002    0x00000000    0x00000000    0x00000000
> 0x7ffff7dd4430 <__gconv_alias_db>:    0x00000000    0x00000000    0x00000000    0x00000000
> 0x7ffff7dd4440 <__gconv_modules_db>:    0x00000000    0x00000000    0x00000000    0x00000000
> 0x7ffff7dd4450 <__gconv_path_envvar>:    0x00000000    0x00000000
> (gdb) p &buffer[99]
> $2 = 0x7ffff7dd4443 <__gconv_modules_db+3> ""
> (gdb) 
> 
> 
> 
> Why I don't see <buffer+32> and similar things?

Because buffer + 32 is the address of the _dl_open_hook
symbol.

What goes inside the <....> is the name of the symbol at the address
presented to its left, it has no direct relation the the expression you
passed to the command.

When there's no symbol at the exact address, <....> shows the name
of closest symbol, plus an offset into the symbol, which is why
you see <buffer+16>.  

Try these:

(gdb) info symbol 0x7ffff7dd4410
__vdso_getcpu in section .bss of /lib64/libc.so.6
(gdb) info symbol 0x7ffff7dd4400
_dl_open_hook in section .bss of /lib64/libc.so.6
(gdb) info symbol 0x7ffff7dd43f0
buffer + 16 in section .bss of /lib64/libc.so.6
(gdb) info symbol 0x7ffff7dd43e0
buffer in section .bss of /lib64/libc.so.6
(gdb) 

Thanks,
Pedro Alves

Re: Viewing the address of an array in gdb

[Pedro Alves]

On 07/06/2018 12:51 PM, Pedro Alves wrote:
> On 07/06/2018 04:33 AM, Mahmood Naderan via gdb wrote:
>> Hi,
>> I have define "char buffer[100]" in a C code. Trying to view the location of buffer in GDB, I see this

Ah, I missed the "you have defined a buffer yourself" part.

So what seems to be happening is that there's another symbol also 
called "buffer" in glibc:

 (gdb) info symbol buffer
 buffer in section .bss of /lib64/libc.so.6

and gdb is picking that symbol instead of yours.

I can reproduce this if I compile a small program without debug info,
but with debug info (-g), it works as you'd expect.

I don't think we have syntax to disambiguate this, like
'libc.so.6'::buffer' vs 'program'::buffer, or program#buffer some
such, unfortunately.

Thanks,
Pedro Alves

Re: Viewing the address of an array in gdb

[Pedro Alves]

On 07/06/2018 01:00 PM, Pedro Alves wrote:
> On 07/06/2018 12:51 PM, Pedro Alves wrote:
>> On 07/06/2018 04:33 AM, Mahmood Naderan via gdb wrote:
>>> Hi,
>>> I have define "char buffer[100]" in a C code. Trying to view the location of buffer in GDB, I see this
> 
> Ah, I missed the "you have defined a buffer yourself" part.
> 
> So what seems to be happening is that there's another symbol also 
> called "buffer" in glibc:
> 
>  (gdb) info symbol buffer
>  buffer in section .bss of /lib64/libc.so.6
> 
> and gdb is picking that symbol instead of yours.
> 
> I can reproduce this if I compile a small program without debug info,
> but with debug info (-g), it works as you'd expect.
> 
> I don't think we have syntax to disambiguate this, like
> 'libc.so.6'::buffer' vs 'program'::buffer, or program#buffer some
> such, unfortunately.
If you can't change the program, you can work around this by
unloading the shared library symbols, so that gdb sees the
program's symbol again.  E.g.:

(gdb) start
Temporary breakpoint 1 at 0x40048b
Starting program: /home/pedro/tmp/buffer 

Temporary breakpoint 1, 0x000000000040048b in main ()
(gdb) info symbol &buffer
buffer in section .bss of /lib64/libc.so.6
(gdb) nosharedlibrary 
(gdb) info symbol &buffer
buffer in section .bss
(gdb) x /30x  &buffer
0x601040 <buffer>:      0x00000000      0x00000000      0x00000000      0x00000000
0x601050 <buffer+16>:   0x00000000      0x00000000      0x00000000      0x00000000
0x601060 <buffer+32>:   0x00000000      0x00000000      0x00000000      0x00000000
0x601070 <buffer+48>:   0x00000000      0x00000000      0x00000000      0x00000000
0x601080 <buffer+64>:   0x00000000      0x00000000      0x00000000      0x00000000
0x601090 <buffer+80>:   0x00000000      0x00000000      0x00000000      0x00000000
0x6010a0 <buffer+96>:   0x00000000      0x00000000      0x00000000      0x00000000
0x6010b0:       0x00000000      0x00000000
(gdb) 

Thanks,
Pedro Alves

Re: Viewing the address of an array in gdb

[Mahmood Naderan via gdb]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 22009 bytes --]

Yes you are right. It picked the glibc symbol name "buffer". 
No matters. I will change the name. I thought there is something wrong with the buffer I defined.
Thank you very much.


Regards,
Mahmood 




    On Friday, July 6, 2018, 4:36:41 PM GMT+4:30, Pedro Alves <palves@redhat.com> wrote: 
If you can't change the program, you can work around this by
unloading the shared library symbols, so that gdb sees the
program's symbol again.  E.g.:

(gdb) start
Temporary breakpoint 1 at 0x40048b
Starting program: /home/pedro/tmp/buffer 

Temporary breakpoint 1, 0x000000000040048b in main ()
(gdb) info symbol &buffer
buffer in section .bss of /lib64/libc.so.6
(gdb) nosharedlibrary 
(gdb) info symbol &buffer
buffer in section .bss
(gdb) x /30x  &buffer
0x601040 <buffer>:      0x00000000      0x00000000      0x00000000      0x00000000
0x601050 <buffer+16>:  0x00000000      0x00000000      0x00000000      0x00000000
0x601060 <buffer+32>:  0x00000000      0x00000000      0x00000000      0x00000000
0x601070 <buffer+48>:  0x00000000      0x00000000      0x00000000      0x00000000
0x601080 <buffer+64>:  0x00000000      0x00000000      0x00000000      0x00000000
0x601090 <buffer+80>:  0x00000000      0x00000000      0x00000000      0x00000000
0x6010a0 <buffer+96>:  0x00000000      0x00000000      0x00000000      0x00000000
0x6010b0:      0x00000000      0x00000000
(gdb) 

Thanks,
Pedro Alves
  
From gdb-return-46510-listarch-gdb=sources.redhat.com@sourceware.org Fri Jul 06 13:08:51 2018
Return-Path: <gdb-return-46510-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 127911 invoked by alias); 6 Jul 2018 13:08:51 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 127897 invoked by uid 89); 6 Jul 2018 13:08:51 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:PHrt, H*c:alternative, H*x:5.0, H*c:HHHHH
X-HELO: sonic301-3.consmr.mail.bf2.yahoo.com
Received: from sonic301-3.consmr.mail.bf2.yahoo.com (HELO sonic301-3.consmr.mail.bf2.yahoo.com) (74.6.129.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jul 2018 13:08:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t\x1530882528; bh=G2ZoKKb+xKZcJ5aa+WJ/3GRCMo2FSKj66wOZNOQXhrM=; hÚte:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=YD6TOIK/ZHQKX8DD7zAH0bvwaMKknthMbZP+sGHxNlVzdMYpUS+0Ef9O87Uev0IeVFkXrnFJFxPxFP/Uk/rEkU8f/RzulCIif5ULqzuyuuk2pLbrNtdeBRLcZvQmeVp3Sij88jC5RoV8K/lHYA4DzdN+i5OQ/KZFK3p/7mtaH6TLL/KlzAcOSxI17KEDvpLyJrin8gWtOVL+eCUS6YURVl6U1FIIrBPOatit3X+O/fvjQn+IyWwTjkzKbj1Nqc4YBAquE2oN5pzaWdxRrcik4iL8+TdvjPb7U3iu1eFs1Xn9clLxTac6ErOb0a07QXu1kBg43Gzjlu3j9yVW/7FP0g=Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Fri, 6 Jul 2018 13:08:48 +0000
Date: Fri, 06 Jul 2018 13:08:00 -0000
From: "Mahmood Naderan via gdb" <gdb@sourceware.org>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
To: "gdb@sourceware.org" <gdb@sourceware.org>, 	Pedro Alves <palves@redhat.com>
Message-ID: <1251589382.60449.1530882523908@mail.yahoo.com>
In-Reply-To: <cc4b1273-31f1-27e6-f6dd-39cb34c84691@redhat.com>
References: <1839186466.17059.1530875705518.ref@mail.yahoo.com> <1839186466.17059.1530875705518@mail.yahoo.com> <111043354.25205.1530876761267@mail.yahoo.com> <cc4b1273-31f1-27e6-f6dd-39cb34c84691@redhat.com>
Subject: Re: debugging a callq command
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
X-SW-Source: 2018-07/txt/msg00022.txt.bz2
Content-length: 614

Right. Something happened in callq. 

Thank you very much.

Regards,
Mahmood 




    On Friday, July 6, 2018, 4:18:39 PM GMT+4:30, Pedro Alves <palves@redhat.com> wrote:  
 
 On 07/06/2018 12:32 PM, Mahmood Naderan via gdb wrote:
something else while the program receives seg fault.

Are you maybe confusing stepi with nexti?  nexti steps over the call
instruction, and then it sounds like something crashes within the
called routine at 0x7fffffffde70.  Try "stepi" to follow the full
instruction flow instead, and it will probably crash at the same
instruction.

Thanks,
Pedro Alves
  
From gdb-return-46511-listarch-gdb=sources.redhat.com@sourceware.org Sat Jul 07 16:15:58 2018
Return-Path: <gdb-return-46511-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 25674 invoked by alias); 7 Jul 2018 16:15:32 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 25438 invoked by uid 89); 7 Jul 2018 16:15:04 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy5, SIGSEGV, crashes, H*c:PHrt
X-HELO: sonic316-13.consmr.mail.bf2.yahoo.com
Received: from sonic316-13.consmr.mail.bf2.yahoo.com (HELO sonic316-13.consmr.mail.bf2.yahoo.com) (74.6.130.123) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 07 Jul 2018 16:15:03 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t\x1530980101; bh=CY313Hbk2DQbJK4TKttzHT2vvSls6qYI/Sjwh9RtMYA=; hÚte:From:Reply-To:To:Subject:References:From:Subject; b=AWZBZV69A/Vc7MQfnLzZ78CJhmPSVoetJgP4I+NdiYUq0qVYO82X50SFLzxuMgwKtqx35+KixAjLxTdf10+WFYzZJO/pWn/NGF+1bzHF6dEryu4zkJ+Ng9LJqu1MXpGbTJKqEveaA0yslDXgBePjqyPRigkgEchthpCa0lEP59wK3rwZVFFrKSM2doW6Ywipa3tkSNoliLoUQzbB1cBOr6s313YwE/9iW/AAjz2SFw4FGJWO6g4ACrZiltE85O1iFTHJsSd8Cl5KzsgFdyFdtSk4FHD9TbrnEQ1UwHNU1Nn2r54UzxFyiptqKEJB7FewhS5DGuMpNNPyg27BRbZ4Mw=Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sat, 7 Jul 2018 16:15:01 +0000
Date: Sat, 07 Jul 2018 16:15:00 -0000
From: "Mahmood Naderan via gdb" <gdb@sourceware.org>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
To: "gdb@sourceware.org" <gdb@sourceware.org>
Message-ID: <1810093935.481654.1530980099373@mail.yahoo.com>
Subject: Debugging issue with -m32 program
MIME-Version: 1.0
References: <1810093935.481654.1530980099373.ref@mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
X-SW-Source: 2018-07/txt/msg00023.txt.bz2
Content-length: 2295

Hello,
I have compiled a simple c program with -m32 option. Thing is that when I want to copy some data into an array, it crashes 


Breakpoint 1, main (argc=1, argv=0xffffd154) at vuln.c:35
35      strcpy( dest, buffer );
(gdb) p &buffer[0]
$1 = 0xffffcfb5 '\220' <repeats 50 times>, "\061\300Ph//shh/bin\211\343P\211\342S\211\341\260\v̀", '\220' <repeats 37 times>, "P\336\377\377\377\177"
(gdb) p &dest[0]
$2 = 0xffffd02c "\020\334\377", <incomplete sequence \367>
(gdb) x/100x 0xffffcfb5
0xffffcfb5:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffcfc5:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffcfd5:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffcfe5:    0xc0319090    0x2f2f6850    0x2f686873    0x896e6962
0xffffcff5:    0xe28950e3    0xb0e18953    0x9080cd0b    0x90909090
0xffffd005:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffd015:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffd025:    0xffffde50    0x10007fff    0x00f7ffdc    0x5cf7ffca
0xffffd035:    0xe0ffffd1    0xb7000000    0xe0f7f047    0x90f7ffdd
0xffffd045:    0x00ffffd0    0x00000000    0x00000000    0x2c000000
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
0x56555655 in main (argc=<error reading variable: Cannot access memory at address 0x90909090>, 
    argv=<error reading variable: Cannot access memory at address 0x90909094>) at vuln.c:37
37    }




Without specifying -m32, there is no problem. I wonder why it tries to access 0x90909090. There is some problem with 32/64 bit data.





Regards,
Mahmood
From gdb-return-46512-listarch-gdb=sources.redhat.com@sourceware.org Mon Jul 09 07:19:15 2018
Return-Path: <gdb-return-46512-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 53954 invoked by alias); 9 Jul 2018 07:19:14 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 53933 invoked by uid 89); 9 Jul 2018 07:19:13 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=segmentation, strcpy, 37, H*c:PHrt
X-HELO: sonic316-15.consmr.mail.bf2.yahoo.com
Received: from sonic316-15.consmr.mail.bf2.yahoo.com (HELO sonic316-15.consmr.mail.bf2.yahoo.com) (74.6.130.125) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jul 2018 07:19:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t\x1531120750; bh=gVOs3t+88yOPq7Wt4VD+KOWVMxcPTM8gTjZUlkozW7w=; hÚte:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=iz4+pkblroiJIclJORoAOOsyJaW3RzX1cLRUqaGQlQZvCZfD6M3B4VmiKC/r5n2R72nBDfqrkt6Uc7Km+gk8rVKAb6yq4IwcUpcx6ilBKU0kHV7YRR77LP2NZG9hkE/wAgwEFNe9i5SQjzbIimAPRUXq97A84vBF8wWoiS5XyKL24Fw/oWYP8DcfxGw7u8J8Gm9sHeZKA8/CrVeKipGG7mRk0+wkY4eu5NvuevyPFNBqEY95MepABRLcwHBpPnfu+J2XqZHzP8YFMf+Lu9cwrCKl2hrAbeBOxkNALTx38jw3Yf1cZsfddn03RlEXKDxmPxjS32YO4kUvwyE024z2tQ=Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 9 Jul 2018 07:19:10 +0000
Date: Mon, 09 Jul 2018 07:19:00 -0000
From: "Mahmood Naderan via gdb" <gdb@sourceware.org>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
To: "gdb@sourceware.org" <gdb@sourceware.org>
Message-ID: <1899779916.938872.1531120747010@mail.yahoo.com>
In-Reply-To: <1810093935.481654.1530980099373@mail.yahoo.com>
References: <1810093935.481654.1530980099373.ref@mail.yahoo.com> <1810093935.481654.1530980099373@mail.yahoo.com>
Subject: Re: Debugging issue with -m32 program
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
X-SW-Source: 2018-07/txt/msg00024.txt.bz2
Content-length: 2450

No idea?


Regards,
Mahmood 

    On Saturday, July 7, 2018, 8:46:01 PM GMT+4:30, Mahmood Naderan via gdb <gdb@sourceware.org> wrote:  
 
 Hello,
I have compiled a simple c program with -m32 option. Thing is that when I want to copy some data into an array, it crashes 


Breakpoint 1, main (argc=1, argv=0xffffd154) at vuln.c:35
35      strcpy( dest, buffer );
(gdb) p &buffer[0]
$1 = 0xffffcfb5 '\220' <repeats 50 times>, "\061\300Ph//shh/bin\211\343P\211\342S\211\341\260\v̀", '\220' <repeats 37 times>, "P\336\377\377\377\177"
(gdb) p &dest[0]
$2 = 0xffffd02c "\020\334\377", <incomplete sequence \367>
(gdb) x/100x 0xffffcfb5
0xffffcfb5:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffcfc5:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffcfd5:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffcfe5:    0xc0319090    0x2f2f6850    0x2f686873    0x896e6962
0xffffcff5:    0xe28950e3    0xb0e18953    0x9080cd0b    0x90909090
0xffffd005:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffd015:    0x90909090    0x90909090    0x90909090    0x90909090
0xffffd025:    0xffffde50    0x10007fff    0x00f7ffdc    0x5cf7ffca
0xffffd035:    0xe0ffffd1    0xb7000000    0xe0f7f047    0x90f7ffdd
0xffffd045:    0x00ffffd0    0x00000000    0x00000000    0x2c000000
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
0x56555655 in main (argc=<error reading variable: Cannot access memory at address 0x90909090>, 
    argv=<error reading variable: Cannot access memory at address 0x90909094>) at vuln.c:37
37    }




Without specifying -m32, there is no problem. I wonder why it tries to access 0x90909090. There is some problem with 32/64 bit data.





Regards,
Mahmood  
From gdb-return-46513-listarch-gdb=sources.redhat.com@sourceware.org Mon Jul 09 12:14:25 2018
Return-Path: <gdb-return-46513-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 45415 invoked by alias); 9 Jul 2018 12:14:24 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 45397 invoked by uid 89); 9 Jul 2018 12:14:23 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=onward, segv, gdbsourcewareorg, H*r:192.168.10
X-HELO: resqmta-po-12v.sys.comcast.net
Received: from resqmta-po-12v.sys.comcast.net (HELO resqmta-po-12v.sys.comcast.net) (96.114.154.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jul 2018 12:14:22 +0000
Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225])	by resqmta-po-12v.sys.comcast.net with ESMTP	id cUmJfeqOOVNwlcV3bffmIR; Mon, 09 Jul 2018 12:14:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;	s=q20161114; t\x1531138459;	bh=xxk7+kWRbuVEziEU7ONymGMmK84VqH8wAJuNePKjRpE=;	h=Received:Received:From:Content-Type:Mime-Version:Subject:Date:To:	 Message-Id;	bølplggcr4jBS8Hq2uTXb34r35Jl9LLKE6euwkj7v8lkHYJcwe4vGStgaRFJcj8te	 brPCg59rX8WuAhqSM35t77fa0j84OM70XBrB0DeghaOIwFZoKdbfBcvL3Yplo9uPwa	 LEC6LdueJVOvIWZoAT/jKojJL8rscsWYKBkbOXVcyFyjTfbfpmkCcgJj2Doout2Cdx	 pSza3mUqo9c4h5yEqHZNyElzOoqYOpfqE+AxI8HEWtioBLY8DpRdV2eMFWvDbh+zib	 IgiJg72drjtYmuI28Laey70VdHgdlrk+EBNfcU2Y+vLsrPSN4pGrVdGOZ3Gp+BLKvW	 PtREsAeCMUldw=Received: from [192.168.10.125] ([73.60.223.101])	by resomta-po-01v.sys.comcast.net with ESMTPA	id cV3afpkdYVGSOcV3bfcR2s; Mon, 09 Jul 2018 12:14:19 +0000
From: Paul Koning <paulkoning@comcast.net>
Content-Type: text/plain;	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Subject: Re: Debugging issue with -m32 program
Date: Mon, 09 Jul 2018 12:14:00 -0000
References: <1810093935.481654.1530980099373.ref@mail.yahoo.com> <1810093935.481654.1530980099373@mail.yahoo.com> <1899779916.938872.1531120747010@mail.yahoo.com>
To: Mahmood Naderan <nt_mahmood@yahoo.com>, "gdb@sourceware.org" <gdb@sourceware.org>
In-Reply-To: <1899779916.938872.1531120747010@mail.yahoo.com>
Message-Id: <2E370BA9-E695-4557-AE57-20E68561ACCE@comcast.net>
X-SW-Source: 2018-07/txt/msg00025.txt.bz2
Content-length: 2179



> On Jul 9, 2018, at 3:19 AM, Mahmood Naderan via gdb <gdb@sourceware.org> wrote:
> 
> ...
> Hello,
> I have compiled a simple c program with -m32 option. Thing is that when I want to copy some data into an array, it crashes 
> 
> 
> Breakpoint 1, main (argc=1, argv=0xffffd154) at vuln.c:35
> 35      strcpy( dest, buffer );
> (gdb) p &buffer[0]
> $1 = 0xffffcfb5 '\220' <repeats 50 times>, "\061\300Ph//shh/bin\211\343P\211\342S\211\341\260\v̀", '\220' <repeats 37 times>, "P\336\377\377\377\177"
> (gdb) p &dest[0]
> $2 = 0xffffd02c "\020\334\377", <incomplete sequence \367>
> (gdb) x/100x 0xffffcfb5
> 0xffffcfb5:    0x90909090    0x90909090    0x90909090    0x90909090
> 0xffffcfc5:    0x90909090    0x90909090    0x90909090    0x90909090
> 0xffffcfd5:    0x90909090    0x90909090    0x90909090    0x90909090
> 0xffffcfe5:    0xc0319090    0x2f2f6850    0x2f686873    0x896e6962
> 0xffffcff5:    0xe28950e3    0xb0e18953    0x9080cd0b    0x90909090
> 0xffffd005:    0x90909090    0x90909090    0x90909090    0x90909090
> 0xffffd015:    0x90909090    0x90909090    0x90909090    0x90909090
> 0xffffd025:    0xffffde50    0x10007fff    0x00f7ffdc    0x5cf7ffca
> 0xffffd035:    0xe0ffffd1    0xb7000000    0xe0f7f047    0x90f7ffdd
> 0xffffd045:    0x00ffffd0    0x00000000    0x00000000    0x2c000000
> (gdb) next
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x56555655 in main (argc=<error reading variable: Cannot access memory at address 0x90909090>, 
>     argv=<error reading variable: Cannot access memory at address 0x90909094>) at vuln.c:37
> 37    }
> 
> 
> 
> 
> Without specifying -m32, there is no problem. I wonder why it tries to access 0x90909090. There is some problem with 32/64 bit data.

If "argc" is not used in "main" -- or at least not from this point onward -- then the compiler can reuse that register for other purposes.  That is probably what is happening here.  Note that this explains the messages in the traceback, but that isn't the reason for the SEGV.  The SEGV is an issue in your program.  Did you overwrite memory by strcpy to an output that's too small?

	paul
From gdb-return-46514-listarch-gdb=sources.redhat.com@sourceware.org Mon Jul 09 19:43:01 2018
Return-Path: <gdb-return-46514-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 124700 invoked by alias); 9 Jul 2018 19:43:01 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 124229 invoked by uid 89); 9 Jul 2018 19:43:00 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:HHHHHHH, HTo:D*comcast.net, H*c:PHrt, Hx-languages-length:678
X-HELO: sonic311-14.consmr.mail.bf2.yahoo.com
Received: from sonic311-14.consmr.mail.bf2.yahoo.com (HELO sonic311-14.consmr.mail.bf2.yahoo.com) (74.6.131.124) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jul 2018 19:42:59 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t\x1531165378; bh=f+CLTdvUYf/3UJbxUqlYcUYyjYNIXwYFIb4ovLMkNRo=; hÚte:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=q58Iurj6E70YXPDgLT18buajDFADbNdTRWMINH4PhYm7qnjugCee4UTXHniBdpzjfsdoNf6YkceRVBK3MLEvOd79LDqYIvF9wDYbbQdsJVUpmqRoc9Vw5r4di3pbihHH90n7+8VgDSc0efCOyN8/xNXscLhIvtOh/zzgWUDt8xAEmJfuEEyzgjln5TyI4QfYZSvTkF0n6SUDyeEf/B1Mm7XqPTgET6E460P7KliK2lNQ0MqqqGh69qE/zuT57BQkQIku5zb5q2l7rGkqJkTQi2BGItIZ1TO7vWBJLANSsKLVclvPd+G4I3tVB34Lb8gryXuQ1TThXWcDgbSTLjxBzg=Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Mon, 9 Jul 2018 19:42:58 +0000
Date: Mon, 09 Jul 2018 19:43:00 -0000
From: "Mahmood Naderan via gdb" <gdb@sourceware.org>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
Reply-To: Mahmood Naderan <nt_mahmood@yahoo.com>
To: "gdb@sourceware.org" <gdb@sourceware.org>, 	Paul Koning <paulkoning@comcast.net>
Message-ID: <1134645069.1279850.1531165376015@mail.yahoo.com>
In-Reply-To: <2E370BA9-E695-4557-AE57-20E68561ACCE@comcast.net>
References: <1810093935.481654.1530980099373.ref@mail.yahoo.com> <1810093935.481654.1530980099373@mail.yahoo.com> <1899779916.938872.1531120747010@mail.yahoo.com> <2E370BA9-E695-4557-AE57-20E68561ACCE@comcast.net>
Subject: Re: Debugging issue with -m32 program
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
X-SW-Source: 2018-07/txt/msg00026.txt.bz2
Content-length: 321

>Did you overwrite memory by strcpy to an output that's too small?

Indeed yes. But not too small. The buffer is more than 100 characters while dest is 100 characters. The question is why the same program, without specifying -m32, works actually?!
Which one is correct behavior? Crash or not crash?!


Regards,
Mahmood