This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: .debug_info in gas


At 04:23 PM 31-10-02 +0200, Elias Athanasopoulos wrote:
>I had discussed this issue with Richard Henderson a while ago. Pasting the
>DWARF3 specification:
>
>7.5  Format of Debugging Information
>
>For each compilation unit compiled with a DWARF Version 3 producer, 
>a contribution is made to the .debug_info section of the object file.
>
>At the moment, gas contibutes only the first source file it assembles
>in .debug_info. When I proposed to make the change, in order to have
>mulitple records in .debug_info for every compilation unit, Richard
>told me that this isn't right. Why?

Your description isn't clear enough about what you are trying to achieve to
give a definitive answer.

Are you trying to output multiple compile unit tags into a single
compilation unit table?

I raised this possibility in the DWARF3 mailing list about a year ago.
The opinion at the time was that this was a "nice" idea but the standard
was not sufficient clear either way to make a conclusive decision.

Arguments for being able to do this is:
1.   The DW_AT_sibling tag is described as a suitable tag on a
DW_TAG_compile_unit in Appendix A.     If there can't be a sibling you can
never have this attribute.

Arguments against being able to do this are:
1.   Sections 6.1.1 and 6.1.2 have entries which refer to the compilation
unit header and not the compile unit tag.
2.   Section 7.5.1 last paragraph.   "The compilation unit header does not
replace *the* DW_TAG_compile_unit debugging information entry."
[Emphasis on "the" added]
3.   Most DWARF2/3 consumers currently assume that there will be only one
entry.



Otherwise, are you trying to output multiple compilation unit tables?

I would then suggest it depends whether you are wanting to conform to the
"simple normal compilation" model, or the more complex space compression
and duplicate elimination techniques describe in section 3.1.1 and Appendix E.


Keith

Keith Walker		keith.walker@arm.com		Tel:+44 (1628) 427732
ARM Ltd		http://www.arm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]