From 21310171@zju.edu.cn  Mon Nov 10 08:55:18 2014
From: 21310171@zju.edu.cn (21310171)
Date: Mon, 10 Nov 2014 16:55:18 +0800
Subject: [Dwarf-Discuss] The difference between .eh_frame section and
	.debug_frame section
Message-ID: <201411101655183684410@zju.edu.cn>


Complie a simple case ,  such as hello.c, with the "-g" parameter to compiler. And use readelf -S tools to analyze the sections of the  output elf file, we see .eh_frame and .debug_frame section. 
.eh_frame and .debug_frame both are something to do with frame stack. Use readelf -Wwf to analyse these two sections . What i find is that their format and contents are rather similar with each other. 
I refer to the dwarf debugging standards, only to see introduction to .debug_frame section, no descriptions about .eh_frame at all. Also, i tried to get information from web, but got little.
Also, i found .eh_frame has allocte attribute, it will be loaded ?
It will be so nice, if someone can tell me something about .eh_frame, better to introduce in comparison with .debug_frame section, Thank you guys!
gcc version :  4.1.2


jiangs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20141110/4480a129/attachment.htm>


From mjw@redhat.com  Mon Nov 10 09:43:32 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Mon, 10 Nov 2014 10:43:32 +0100
Subject: [Dwarf-Discuss] The difference between .eh_frame section and
 .debug_frame section
In-Reply-To: <201411101655183684410@zju.edu.cn>
References: <201411101655183684410@zju.edu.cn>
Message-ID: <1415612612.4965.3.camel@bordewijk.wildebeest.org>

On Mon, 2014-11-10 at 16:55 +0800, 21310171 wrote:
> Complie a simple case ,  such as hello.c, with the "-g" parameter to compiler. And use readelf -S tools to analyze the sections of the  output elf file, we see .eh_frame and .debug_frame section. 
> .eh_frame and .debug_frame both are something to do with frame stack. Use readelf -Wwf to analyse these two sections . What i find is that their format and contents are rather similar with each other. 
> I refer to the dwarf debugging standards, only to see introduction to .debug_frame section, no descriptions about .eh_frame at all. Also, i tried to get information from web, but got little.
> Also, i found .eh_frame has allocte attribute, it will be loaded ?
> It will be so nice, if someone can tell me something about .eh_frame, better to introduce in comparison with .debug_frame section, Thank you guys!

DWARF only describes the .debug_frame format. The .eh_frame format is
based on that, but subtly different. The following describes
the .eh_frame (and .eh_frame_hdr) sections:
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
It uses the following DWARF extensions:
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/dwarfext.html


From me.swar@gmail.com  Tue Nov 11 10:03:36 2014
From: me.swar@gmail.com (Swarup Sahoo)
Date: Tue, 11 Nov 2014 15:33:36 +0530
Subject: [Dwarf-Discuss] C++ implicit inline member function
Message-ID: <CANM4mahXE-U4gcNcr0rkdDo_rTWqoD7LVOkSiJTD0seN_sC=FQ@mail.gmail.com>

Hi,
I have observed that implicit inline member functions info is not getting
captured in .debug_info section. Usually explicitly declared inlined
function info is getting captured. But implicit inline member functions,
though they are getting inlined in the executable, but no
DW_TAG_inlined_subroutine entry is stored for these functions. Is this
compiler (GCC) side limitation or DWARF standard limitation?

I tried with the following setup:

Compiler: G++/GCC 4.8.2, Clang++/LLVM 3.4

DWARF version: 4

Sample program:

class test
{
    private:
        // some private members

    public:
        // this is an implicit inline member function
        void small_func()
        {
            // do some operation
        }

        void big_func();
};

void test::big_func()
{
    // call small_func()
}

int main()
{
    test t1 ;
    t1.big_func();
    return 0;
}



Regards,
Swarup
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20141111/c91500de/attachment.htm>


From eager@eagerm.com  Tue Nov 11 15:15:48 2014
From: eager@eagerm.com (Michael Eager)
Date: Tue, 11 Nov 2014 07:15:48 -0800
Subject: [Dwarf-Discuss] C++ implicit inline member function
In-Reply-To: <CANM4mahXE-U4gcNcr0rkdDo_rTWqoD7LVOkSiJTD0seN_sC=FQ@mail.gmail.com>
References: <CANM4mahXE-U4gcNcr0rkdDo_rTWqoD7LVOkSiJTD0seN_sC=FQ@mail.gmail.com>
Message-ID: <54622824.8040004@eagerm.com>

On 11/11/14 02:03, Swarup Sahoo wrote:
> Hi,
> I have observed that implicit inline member functions info is not getting captured in .debug_info
> section. Usually explicitly declared inlined function info is getting captured. But implicit inline
> member functions, though they are getting inlined in the executable, but no
> DW_TAG_inlined_subroutine entry is stored for these functions. Is this compiler (GCC) side
> limitation or DWARF standard limitation?
>
> I tried with the following setup:
>
> Compiler: G++/GCC 4.8.2, Clang++/LLVM 3.4
>
> DWARF version: 4
>
> Sample program:
>
> class test
> {
>      private:
>          // some private members
>      public:
>          // this is an implicit inline member function
>          void small_func()
>          {
>              // do some operation
>          }
>
>          void big_func();
> };
>
> void test::big_func()
> {
>      // call small_func()
> }
>
> int main()
> {
>      test t1 ;
>      t1.big_func();
>      return 0;
> }

Please post the DWARF which is generated and what you
believe should be generated.

I notice that your example doesn't call small_func().


-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


From me.swar@gmail.com  Fri Nov 14 20:56:19 2014
From: me.swar@gmail.com (Swarup Sahoo)
Date: Sat, 15 Nov 2014 02:26:19 +0530
Subject: [Dwarf-Discuss] C++ implicit inline member function
In-Reply-To: <54622824.8040004@eagerm.com>
References: <CANM4mahXE-U4gcNcr0rkdDo_rTWqoD7LVOkSiJTD0seN_sC=FQ@mail.gmail.com>
	<54622824.8040004@eagerm.com>
Message-ID: <CANM4maj_c9F1w1qBaKqQRLYb-Nqk6CUma0U-1=7TJgeq-gdVxw@mail.gmail.com>

Sorry for my late reply.

I think I overlooked the DWARF output last time. Rechecked the DWARF output
and looks everything fine.



Regards,
Swarup


On Tue, Nov 11, 2014 at 8:45 PM, Michael Eager <eager at eagerm.com> wrote:

> On 11/11/14 02:03, Swarup Sahoo wrote:
>
>> Hi,
>> I have observed that implicit inline member functions info is not getting
>> captured in .debug_info
>> section. Usually explicitly declared inlined function info is getting
>> captured. But implicit inline
>> member functions, though they are getting inlined in the executable, but
>> no
>> DW_TAG_inlined_subroutine entry is stored for these functions. Is this
>> compiler (GCC) side
>> limitation or DWARF standard limitation?
>>
>> I tried with the following setup:
>>
>> Compiler: G++/GCC 4.8.2, Clang++/LLVM 3.4
>>
>> DWARF version: 4
>>
>> Sample program:
>>
>> class test
>> {
>>      private:
>>          // some private members
>>      public:
>>          // this is an implicit inline member function
>>          void small_func()
>>          {
>>              // do some operation
>>          }
>>
>>          void big_func();
>> };
>>
>> void test::big_func()
>> {
>>      // call small_func()
>> }
>>
>> int main()
>> {
>>      test t1 ;
>>      t1.big_func();
>>      return 0;
>> }
>>
>
> Please post the DWARF which is generated and what you
> believe should be generated.
>
> I notice that your example doesn't call small_func().
>
>
> --
> Michael Eager    eager at eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20141115/08e7667b/attachment.htm>


From mjw@redhat.com  Tue Nov 25 12:49:05 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Tue, 25 Nov 2014 13:49:05 +0100
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <54352A6C.3070206@redhat.com>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
	<54352A6C.3070206@redhat.com>
Message-ID: <1416919745.4954.15.camel@bordewijk.wildebeest.org>

On Wed, 2014-10-08 at 08:13 -0400, Jason Merrill wrote:
> On 10/08/2014 06:57 AM, Mark Wielaard wrote:
> > I also had a question about issue 120628.1 which proposes to add
> > DW_LANG_C_plus_plus_03. The current DWARFv4 DW_LANG_C_plus_plus says it
> > is for ISO C++:1998. As far as I know C++03 (unlike C++11 and C++14)
> > didn't add any language changes, so I think for producers and consumers
> > C++98 and C++03 look similar. When would consumers expect to see
> > DW_LANG_C_plus_plus and when DW_LANG_C_plus_plus_03?
> 
> Agreed, C++03 is just C++98 with some DRs.

Has the committee discussed what should happen to
DW_LANG_C_plus_plus_03? And if it will be kept what the expectation on
producers and consumers are vs DW_LANG_C_plus_plus?

Thanks,

Mark


From eager@eagerm.com  Tue Nov 25 15:54:18 2014
From: eager@eagerm.com (Michael Eager)
Date: Tue, 25 Nov 2014 07:54:18 -0800
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1416919745.4954.15.camel@bordewijk.wildebeest.org>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>	<54352A6C.3070206@redhat.com>
	<1416919745.4954.15.camel@bordewijk.wildebeest.org>
Message-ID: <5474A62A.6020209@eagerm.com>

On 11/25/14 04:49, Mark Wielaard wrote:
> On Wed, 2014-10-08 at 08:13 -0400, Jason Merrill wrote:
>> On 10/08/2014 06:57 AM, Mark Wielaard wrote:
>>> I also had a question about issue 120628.1 which proposes to add
>>> DW_LANG_C_plus_plus_03. The current DWARFv4 DW_LANG_C_plus_plus says it
>>> is for ISO C++:1998. As far as I know C++03 (unlike C++11 and C++14)
>>> didn't add any language changes, so I think for producers and consumers
>>> C++98 and C++03 look similar. When would consumers expect to see
>>> DW_LANG_C_plus_plus and when DW_LANG_C_plus_plus_03?
>>
>> Agreed, C++03 is just C++98 with some DRs.
>
> Has the committee discussed what should happen to
> DW_LANG_C_plus_plus_03? And if it will be kept what the expectation on
> producers and consumers are vs DW_LANG_C_plus_plus?

There have been no proposals submitted to the DWARF Committee regarding
DW_LANG_C_plus_plus_03 since this language code was requested in Issue 120628.1:
http://dwarfstd.org/ShowIssue.php?issue=120628.1
Accordingly, the DWARF Committee has had no discussions about this code.

Issue 120628.1 mentions a need to distinguish between C++03 and other
versions of C++.  If you believe that DW_LANG_C_plus_plus_03 is not
necessary, I suggest that you discuss this with the submitter, Tom
Tromey, to understand why he believes that this is required.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


From mjw@redhat.com  Wed Nov 26 10:23:21 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Wed, 26 Nov 2014 11:23:21 +0100
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <87tx1n46b9.fsf@tromey.com>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
	<54352A6C.3070206@redhat.com>
	<1416919745.4954.15.camel@bordewijk.wildebeest.org>
	<5474A62A.6020209@eagerm.com> <87tx1n46b9.fsf@tromey.com>
Message-ID: <1416997401.4954.19.camel@bordewijk.wildebeest.org>

Looks like Tom's reply never made the dwarf mailinglist.
So here it is to make the archive on this issue complete.

On Tue, 2014-11-25 at 09:02 -0700, Tom Tromey wrote:
> Michael> Issue 120628.1 mentions a need to distinguish between C++03 and other
> Michael> versions of C++.  If you believe that DW_LANG_C_plus_plus_03 is not
> Michael> necessary, I suggest that you discuss this with the submitter, Tom
> Michael> Tromey, to understand why he believes that this is required.
> 
> Mark & I discussed it and I couldn't remember any reason that this was
> needed.
> 
> Tom



From jakub@redhat.com  Wed Nov 26 10:29:39 2014
From: jakub@redhat.com (Jakub Jelinek)
Date: Wed, 26 Nov 2014 11:29:39 +0100
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1416997401.4954.19.camel@bordewijk.wildebeest.org>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
	<54352A6C.3070206@redhat.com>
	<1416919745.4954.15.camel@bordewijk.wildebeest.org>
	<5474A62A.6020209@eagerm.com> <87tx1n46b9.fsf@tromey.com>
	<1416997401.4954.19.camel@bordewijk.wildebeest.org>
Message-ID: <20141126102939.GE1669@tucnak.redhat.com>

On Wed, Nov 26, 2014 at 11:23:21AM +0100, Mark Wielaard wrote:
> Looks like Tom's reply never made the dwarf mailinglist.
> So here it is to make the archive on this issue complete.
> 
> On Tue, 2014-11-25 at 09:02 -0700, Tom Tromey wrote:
> > Michael> Issue 120628.1 mentions a need to distinguish between C++03 and other
> > Michael> versions of C++.  If you believe that DW_LANG_C_plus_plus_03 is not
> > Michael> necessary, I suggest that you discuss this with the submitter, Tom
> > Michael> Tromey, to understand why he believes that this is required.
> > 
> > Mark & I discussed it and I couldn't remember any reason that this was
> > needed.

I have also submitted an Issue for Fortran 2003 and 2008 lacking
DW_LANG_* codes.
So, if DW_LANG_C_plus_plus_03 is being removed, perhaps the assigned code
could be reused for one of those (or left unassigned).

	Jakub


From daniel.gutson@tallertechnologies.com  Wed Nov 26 13:22:23 2014
From: daniel.gutson@tallertechnologies.com (Daniel Gutson)
Date: Wed, 26 Nov 2014 13:22:23 +0000
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1416997401.4954.19.camel@bordewijk.wildebeest.org>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
	<54352A6C.3070206@redhat.com>
	<1416919745.4954.15.camel@bordewijk.wildebeest.org>
	<5474A62A.6020209@eagerm.com> <87tx1n46b9.fsf@tromey.com>
	<1416997401.4954.19.camel@bordewijk.wildebeest.org>
Message-ID: <1531412020-1417008143-cardhu_decombobulator_blackberry.rim.net-1390399049-@b2.c5.bise6.blackberry>

(Sorry top posting)
What about new C++11 keywords? Would a debugger cli interpreter be helped by this datum in case the user enters some of these keywords? (I can bring the list, only "noexcept" comes from the top of my mind currently)
-----Original Message-----
From: Mark Wielaard <mjw@redhat.com>
Sender: "Dwarf-Discuss" <dwarf-discuss-bounces at lists.dwarfstd.org>Date: Wed, 26 Nov 2014 11:23:21 
To: <dwarf-discuss at lists.dwarfstd.org>
Subject: Re: [Dwarf-Discuss] C++14 and C++03 (vs C++98)

Looks like Tom's reply never made the dwarf mailinglist.
So here it is to make the archive on this issue complete.

On Tue, 2014-11-25 at 09:02 -0700, Tom Tromey wrote:
> Michael> Issue 120628.1 mentions a need to distinguish between C++03 and other
> Michael> versions of C++.  If you believe that DW_LANG_C_plus_plus_03 is not
> Michael> necessary, I suggest that you discuss this with the submitter, Tom
> Michael> Tromey, to understand why he believes that this is required.
> 
> Mark & I discussed it and I couldn't remember any reason that this was
> needed.
> 
> Tom

_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss at lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


From mjw@redhat.com  Wed Nov 26 14:00:07 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Wed, 26 Nov 2014 15:00:07 +0100
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1531412020-1417008143-cardhu_decombobulator_blackberry.rim.net-1390399049-@b2.c5.bise6.blackberry>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
	<54352A6C.3070206@redhat.com>
	<1416919745.4954.15.camel@bordewijk.wildebeest.org>
	<5474A62A.6020209@eagerm.com> <87tx1n46b9.fsf@tromey.com>
	<1416997401.4954.19.camel@bordewijk.wildebeest.org>
	<1531412020-1417008143-cardhu_decombobulator_blackberry.rim.net-1390399049-@b2.c5.bise6.blackberry>
Message-ID: <1417010407.4954.25.camel@bordewijk.wildebeest.org>

On Wed, 2014-11-26 at 13:22 +0000, Daniel Gutson wrote:
> What about new C++11 keywords? Would a debugger cli interpreter be
> helped by this datum in case the user enters some of these keywords?

Yes, that is the intention. If there are different language variants
that have different keywords or when certain DWARF constructs can be
interpreted differently depending on the version used in the source. For
C++11 there certainly is a usage.

But C++03 does not change the language in any way from C++98 represented
by DW_LANG_c_plus_plus. It really isn't a different language variant,
just some library extensions (and the library will be described by
existing DWARF constructs already). So the question is whether the
proposed DW_LANG_c_plus_plus_03 constant is actually needed, and if
adopted by DWARFv5, how a producer and consumer need to interpret it.

Cheers,

Mark


From eager@eagercon.com  Wed Nov 26 15:36:17 2014
From: eager@eagercon.com (Michael Eager)
Date: Wed, 26 Nov 2014 07:36:17 -0800
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1416997401.4954.19.camel@bordewijk.wildebeest.org>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>	<54352A6C.3070206@redhat.com>	<1416919745.4954.15.camel@bordewijk.wildebeest.org>	<5474A62A.6020209@eagerm.com>
	<87tx1n46b9.fsf@tromey.com>
	<1416997401.4954.19.camel@bordewijk.wildebeest.org>
Message-ID: <5475F371.6080401@eagercon.com>

On 11/26/14 02:23, Mark Wielaard wrote:
> Looks like Tom's reply never made the dwarf mailinglist.
> So here it is to make the archive on this issue complete.
>
> On Tue, 2014-11-25 at 09:02 -0700, Tom Tromey wrote:
>> Michael> Issue 120628.1 mentions a need to distinguish between C++03 and other
>> Michael> versions of C++.  If you believe that DW_LANG_C_plus_plus_03 is not
>> Michael> necessary, I suggest that you discuss this with the submitter, Tom
>> Michael> Tromey, to understand why he believes that this is required.
>>
>> Mark & I discussed it and I couldn't remember any reason that this was
>> needed.
>>
>> Tom

Please submit a comment to remove the language code:
http://dwarfstd.org/Comment.php


-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


From daniel.gutson@tallertechnologies.com  Wed Nov 26 16:11:02 2014
From: daniel.gutson@tallertechnologies.com (Daniel Gutson)
Date: Wed, 26 Nov 2014 13:11:02 -0300
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1417010407.4954.25.camel@bordewijk.wildebeest.org>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
	<54352A6C.3070206@redhat.com>
	<1416919745.4954.15.camel@bordewijk.wildebeest.org>
	<5474A62A.6020209@eagerm.com> <87tx1n46b9.fsf@tromey.com>
	<1416997401.4954.19.camel@bordewijk.wildebeest.org>
	<1531412020-1417008143-cardhu_decombobulator_blackberry.rim.net-1390399049-@b2.c5.bise6.blackberry>
	<1417010407.4954.25.camel@bordewijk.wildebeest.org>
Message-ID: <CAF5HaEVdgY5i265fCWLS8MCA2S=VKGNcnxtSwS5peFjcWS9X2Q@mail.gmail.com>

On Wed, Nov 26, 2014 at 11:00 AM, Mark Wielaard <mjw at redhat.com> wrote:
> On Wed, 2014-11-26 at 13:22 +0000, Daniel Gutson wrote:
>> What about new C++11 keywords? Would a debugger cli interpreter be
>> helped by this datum in case the user enters some of these keywords?
>
> Yes, that is the intention. If there are different language variants
> that have different keywords or when certain DWARF constructs can be
> interpreted differently depending on the version used in the source. For
> C++11 there certainly is a usage.
>
> But C++03 does not change the language in any way from C++98 represented

Yes, IIRC it's a corrigendum actually. I got misled by the subject of
the email :) sorry.

> by DW_LANG_c_plus_plus. It really isn't a different language variant,
> just some library extensions (and the library will be described by
> existing DWARF constructs already). So the question is whether the
> proposed DW_LANG_c_plus_plus_03 constant is actually needed, and if
> adopted by DWARFv5, how a producer and consumer need to interpret it.
>
> Cheers,
>
> Mark



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
C?rdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:    dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson


