DW_AT_count is the same as DW_AT_upper_bound?

[Rouslan Korneychuk <rouslank@msn.com>]

I'm working on a program which produces DWARF 4 debug information and
uses GDB's JIT interface. I have an array with a dynamic size with the
following description (taken from objdump):

...
 <2><4e>: Abbrev Number: 7 (DW_TAG_variable)
    <4f>   DW_AT_type        : <0x1d>   
    <50>   DW_AT_name        : (indirect string, offset: 0x2c): stack_len   
    <54>   DW_AT_location    : 0x0    (location list)
 <2><58>: Abbrev Number: 8 (DW_TAG_array_type)
    <59>   DW_AT_type        : <0x29>   
 <3><5a>: Abbrev Number: 9 (DW_TAG_subrange_type)
    <5b>   DW_AT_type        : <0x1d>   
    <5c>   DW_AT_lower_bound : 0   
    <5d>   DW_AT_count       : <0x4e>   
 <3><5e>: Abbrev Number: 0
 <2><5f>: Abbrev Number: 10 (DW_TAG_variable)
    <60>   DW_AT_type        : <0x58>   
    <61>   DW_AT_name        : (indirect string, offset: 0x36): stack   
    <65>   DW_AT_location    : 2 byte block: 91 18     (DW_OP_fbreg: 24)
    <68>   DW_AT_start_scope : 152   
...

The array "stack" uses DW_AT_count which is a reference to the variable
"stack_len". I expected the length of the array to be equal to the value
of "stack_len", but when I use GDB to display these two variables (using
the command "display"), "stack" is always shown with 1 more element than
I expected. e.g.:

...
0x00007ffff7ff31f6 in $module$ (f=0x87f0a0 <small_ints+384>,
    throwflag=-240094128)
3: stack = {0xc33aa0, 0xc33aa0}
2: stack_len = 1
1: x/i $pc
=> 0x7ffff7ff31f6 <$module$+422>:    mov    %rax,0x48(%rsp)
(gdb)  nexti
0x00007ffff7ff31fb in $module$ (f=0x87f0a0 <small_ints+384>,
    throwflag=-240094128)
3: stack = {0xc33aa0, 0xc33aa0, 0x7fffffffce00}
2: stack_len = 2
1: x/i $pc
=> 0x7ffff7ff31fb <$module$+427>:    movabs $0x1,%rsi
(gdb)

I'm using DW_AT_count instead of DW_AT_upper_bound so that "stack" can
be empty (have 0 elements), but these two attributes appear to be
treated the same. Is this a bug or am I misunderstanding something? I'm
using GDB version 7.5.1. 		 	   		  
From gdb-return-42329-listarch-gdb=sources.redhat.com@sourceware.org Fri Jul 05 18:42:57 2013
Return-Path: <gdb-return-42329-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 25009 invoked by alias); 5 Jul 2013 18:42:57 -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 24984 invoked by uid 89); 5 Jul 2013 18:42:54 -0000
X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 05 Jul 2013 18:42:45 +0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r65Igg3P022095	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=OK);	Fri, 5 Jul 2013 14:42:42 -0400
Received: from host2.jankratochvil.net (ovpn-116-27.ams2.redhat.com [10.36.116.27])	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r65Igd9b022696	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits\x128 verify=NO);	Fri, 5 Jul 2013 14:42:41 -0400
Date: Fri, 05 Jul 2013 18:42:00 -0000
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: vijay nag <vijunag@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Fwd: vdso
Message-ID: <20130705184238.GA661@host2.jankratochvil.net>
References: <20130703084207.GA598@host2.jankratochvil.net> <CAKhyrx9xNG6xEtVf51ig-dC93Évrzgi98RzjA4QLyfuE+hkw@mail.gmail.com> <20130703090259.GA1854@host2.jankratochvil.net> <CAKhyrx8nSOR4Sq2K3XbyVytUnQMyn42Xpbo1aX0ß4r5Pebtw@mail.gmail.com> <CAKhyrx_9fSc5wMaXaX76bFOPJbuVFttDNJ-YDa28wz5obJHQyQ@mail.gmail.com> <20130703144857.GA27367@host2.jankratochvil.net> <CAKhyrx8GCE7bYeZe9gnNT_aZN74oM--kd_oZr1+cjqt67oOzVQ@mail.gmail.com> <20130704061052.GA19661@host2.jankratochvil.net> <CAKhyrx8pAR9aKC1=-_HnwJ=ssb4B7LGUYM6CRqxY68xx+duprA@mail.gmail.com> <CAKhyrx_aX76L70XGWes+M2qsMu+n2UhO160YWCkxgGsL5XKA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKhyrx_aX76L70XGWes+M2qsMu+n2UhO160YWCkxgGsL5XKA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-IsSubscribed: yes
X-SW-Source: 2013-07/txt/msg00029.txt.bz2
Content-length: 472

On Fri, 05 Jul 2013 08:12:29 +0200, vijay nag wrote:
> The function linux_proc_xfer_partial() is returning result zero when
> trying to pread64 /proc/<pid>/mem and errno is set to -EIO.

And what is 'offset' (and 'len') that time and what is in /proc/PID/maps that
time?
Isn't there also some incorrect signed extension of 32-bit address to 64-bit
address, for example?


> Does that mean kernel doesn't support pread64 on /proc/xxx/mem files ?

I do not think so.


Jan