From woodzltc Thu Feb 23 18:26:15 2006 From: woodzltc (Wu Zhou) Date: Thu Feb 23 18:26:15 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: Hello, committee members Now that DWARF-3 had been published for a while, can I have the pleasure to re-open this deferred issue? I don't see any action I can do from the net. So I am asking here. Regards - Wu Zhou From eager Thu Feb 23 18:55:33 2006 From: eager (Michael Eager) Date: Thu Feb 23 18:55:33 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: Message-ID: <43FE7590.6010000@eagercon.com> Wu Zhou wrote: > Hello, committee members > > Now that DWARF-3 had been published for a while, can I have the pleasure > to re-open this deferred issue? > > I don't see any action I can do from the net. So I am asking here. > > Regards > - Wu Zhou http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed We will consider revisions to the DWARF standard starting mid-year. The proposal is somewhat vague. I'm personally unclear why there is a need for an new TAG. Saying Stabs does something one way so DWARF should do the same is not persuasive. Is there a reason why using DW_TAG_entry_point doesn't work? Would an attribute work as well? In general, proposals which have been implemented are preferred. -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 From dberlin Thu Feb 23 19:15:04 2006 From: dberlin (Daniel Berlin) Date: Thu Feb 23 19:15:04 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> Message-ID: <1140750905.3599.23.camel@linux.site> On Thu, 2006-02-23 at 18:55 -0800, Michael Eager wrote: > Wu Zhou wrote: > > Hello, committee members > > > > Now that DWARF-3 had been published for a while, can I have the pleasure > > to re-open this deferred issue? > > > > I don't see any action I can do from the net. So I am asking here. > > > > Regards > > - Wu Zhou > > http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed > > We will consider revisions to the DWARF standard starting mid-year. > > The proposal is somewhat vague. I'm personally unclear > why there is a need for an new TAG. Saying Stabs does something > one way so DWARF should do the same is not persuasive. > > Is there a reason why using DW_TAG_entry_point doesn't work? DW_TAG_entry_point was very specifically pointed out to *not* be the same as what he is looking for, IIRC. Though is see in the final version we've listed it as a "fortran alternate entry point", which i presume has some meaning to fortran people. Which is still not the same as the main entry point for a program. Personally, I think DW_TAG_entry_point should have been the main entry point for the program (in terms of what the standard function is named that gets run when you execute the program), and we should have had some *other* tag to represent fortran alternate entry points, or whatever they are called. But it seems too late for that (and it was too late when he first brought it up, AFAIK). > Would an attribute work as well? > > In general, proposals which have been implemented are preferred. We specifically put off adding it to GCC to get resolution *first*, so this is kinda a downer. Why create the chance that someone will do this again a different way, when this is a simple issue that could be resolved once, first? This is not something we need heavy implementation experience to determine whether it is useful or not. But I guess for now, Wu, DW_TAG_GNU_entry_point or whatever should be added. From eager Thu Feb 23 19:40:34 2006 From: eager (Michael Eager) Date: Thu Feb 23 19:40:34 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> Message-ID: <43FE8017.9040309@eagercon.com> Daniel Berlin wrote: > On Thu, 2006-02-23 at 18:55 -0800, Michael Eager wrote: > >>Wu Zhou wrote: >> >>>Hello, committee members >>> >>>Now that DWARF-3 had been published for a while, can I have the pleasure >>>to re-open this deferred issue? >>> >>>I don't see any action I can do from the net. So I am asking here. >>> >>>Regards >>>- Wu Zhou >> >>http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed >> >>We will consider revisions to the DWARF standard starting mid-year. >> >>The proposal is somewhat vague. I'm personally unclear >>why there is a need for an new TAG. Saying Stabs does something >>one way so DWARF should do the same is not persuasive. >> >>Is there a reason why using DW_TAG_entry_point doesn't work? > > > DW_TAG_entry_point was very specifically pointed out to *not* be the > same as what he is looking for, IIRC. As I indicated, the proposal is vague. Also short. The mention of DW_TAG_entry_point along with your name suggests, in an unclear fashion, that you believed it to be adequate. Perhaps this is inaccurate, but that's at least how I read the proposal. >>In general, proposals which have been implemented are preferred. > > We specifically put off adding it to GCC to get resolution *first*, so > this is kinda a downer. Why create the chance that someone will do this > again a different way, when this is a simple issue that could be > resolved once, first? > > This is not something we need heavy implementation experience to determine > whether it is useful or not. > But I guess for now, Wu, DW_TAG_GNU_entry_point or whatever should be added. Again, this is a general principle. Unless there is a clear proposal (which this is not) then the preference is for some demonstration that the proposed change actually addresses the issue. Again, I read the very few lines of the proposal and I don't find it clear. Perhaps making a clear and complete proposal would be a more productive way to get a resolution. -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 From dberlin Thu Feb 23 20:08:15 2006 From: dberlin (Daniel Berlin) Date: Thu Feb 23 20:08:15 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> Message-ID: <1140754080.3599.41.camel@linux.site> On Thu, 2006-02-23 at 19:40 -0800, Michael Eager wrote: > Daniel Berlin wrote: > > On Thu, 2006-02-23 at 18:55 -0800, Michael Eager wrote: > > > >>Wu Zhou wrote: > >> > >>>Hello, committee members > >>> > >>>Now that DWARF-3 had been published for a while, can I have the pleasure > >>>to re-open this deferred issue? > >>> > >>>I don't see any action I can do from the net. So I am asking here. > >>> > >>>Regards > >>>- Wu Zhou > >> > >>http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed > >> > >>We will consider revisions to the DWARF standard starting mid-year. > >> > >>The proposal is somewhat vague. I'm personally unclear > >>why there is a need for an new TAG. Saying Stabs does something > >>one way so DWARF should do the same is not persuasive. > >> > >>Is there a reason why using DW_TAG_entry_point doesn't work? > > > > > > DW_TAG_entry_point was very specifically pointed out to *not* be the > > same as what he is looking for, IIRC. > > As I indicated, the proposal is vague. Also short. > > The mention of DW_TAG_entry_point along with your name suggests, in an > unclear fashion, that you believed it to be adequate. Perhaps this is > inaccurate, but that's at least how I read the proposal. Well, it would be, but we'd need a flag. > > >>In general, proposals which have been implemented are preferred. > > > > We specifically put off adding it to GCC to get resolution *first*, so > > this is kinda a downer. Why create the chance that someone will do this > > again a different way, when this is a simple issue that could be > > resolved once, first? > > > > This is not something we need heavy implementation experience to determine > > whether it is useful or not. > > But I guess for now, Wu, DW_TAG_GNU_entry_point or whatever should be added. > > Again, this is a general principle. Unless there is a clear > proposal (which this is not) then the preference is for some > demonstration that the proposed change actually addresses > the issue. > > Again, I read the very few lines of the proposal and I don't > find it clear. Perhaps making a clear and complete proposal > would be a more productive way to get a resolution. Okay, well, let me simply edit the "proposal" (which i agree is not a proposal) Most C compiler assume the main function to be "main". Other languages might have different names, or even allow it to have any name. If we have an entry to tell what is the main function in a program, it will let the debugger to present this to users in an intelligent way. Another debug-info format stabs could support this with N_MAIN stab type. Proposal: I propose we modify the definition of the DW_TAG_entry_point tag definition to state that it is also usable for specifying the main entry point to a program, not just fortran alternate entry points. In order to determine which of the DW_TAG_entry_point is the single main entry point to the program, a flag attribute DW_AT_is_main(or something suitably named) should be added to the allowed attributes for DW_TAG_entry_point. Alternatively, we could define it as the entry_point with DW_CC_program calling convention, and delete the text that says "The DW_CC_program value is intended to support Fortran main programs. It is not intended as a way of finding the entry address for the program." > From woodzltc Thu Feb 23 20:35:45 2006 From: woodzltc (Wu Zhou) Date: Thu Feb 23 20:35:45 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> Message-ID: On Thu, 23 Feb 2006, Michael Eager wrote: > As I indicated, the proposal is vague. Also short. You said it. This is my fault. I admit that it is short, also not very clear, and also somewhat late. :-) But just as what I said in the issue: "I don't have any detailed proposal yet. But ....". In fact, my intention of submitting this issue is to statement the problem, and to see if we can get any comments (negative or positive) and at last if we can get out a solution for that. That proposal section I added in that issue is indeed not a complete one. I just add some initial idea of mine and some comment from Daniel and others. That might be the origin of confusion. Really sorry for that! All this is attribute to my im-mature idea. Not related to Daniel or any body else! Said that, I am very new to the process of submitting issue to the DWARF group (or any other standard committee). I am very happy to have the chance to do that. But it seems that I didn't do very well. :-( If anybody would like to work together with me to make this proposal better, I am more than happy to do that! > The mention of DW_TAG_entry_point along with your name suggests, in an > unclear fashion, that you believed it to be adequate. Perhaps this is > inaccurate, but that's at least how I read the proposal. Maybe we can put the proposal section aside and discuss the problem itself. My reading of the DWARF standard tells me that DW_TAG_entry_point is reserved for the specific purpose of Fortran alternate entry point. So it is not proper for the general purpose of indicating the main entry. > > > In general, proposals which have been implemented are preferred. > > > > We specifically put off adding it to GCC to get resolution *first*, so > > this is kinda a downer. Why create the chance that someone will do this > > again a different way, when this is a simple issue that could be > > resolved once, first? > > > > This is not something we need heavy implementation experience to determine > > whether it is useful or not. But I guess for now, Wu, > > DW_TAG_GNU_entry_point or whatever should be added. > > Again, this is a general principle. Unless there is a clear > proposal (which this is not) then the preference is for some > demonstration that the proposed change actually addresses > the issue. > > Again, I read the very few lines of the proposal and I don't > find it clear. Perhaps making a clear and complete proposal > would be a more productive way to get a resolution. Thanks for this constructive idea. I will try to make it clearer. Regards - Wu Zhou From drow Thu Feb 23 20:38:50 2006 From: drow (Daniel Jacobowitz) Date: Thu Feb 23 20:38:50 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> Message-ID: <20060224043841.GA12884@nevyn.them.org> On Thu, Feb 23, 2006 at 11:08:00PM -0500, Daniel Berlin wrote: > Proposal: > > I propose we modify the definition of the DW_TAG_entry_point tag > definition to state that it is also usable for specifying the main > entry point to a program, not just fortran alternate entry points. > > In order to determine which of the DW_TAG_entry_point is the single > main entry point to the program, a flag attribute DW_AT_is_main(or > something suitably named) should be added to the allowed attributes > for DW_TAG_entry_point. If we need a new flag anyway, then why shouldn't it be a flag on the DW_TAG_subprogram for main? That seems to me like the clearest choice. "entry point" is an overloaded term already; this isn't necessarily the program's entry point, but the high level language's starting point. The actual entry point will be over in _start land. > Alternatively, we could define it as the entry_point with > DW_CC_program calling convention, and delete the text that says "The > DW_CC_program value is intended to support Fortran main programs. It > is not intended as a way of finding the entry address for the > program." This isn't appropriate because it would interfere with any other DW_AT_calling_convention that applied to the main routine - for instance, sh-elf-gcc with -mrenesas will mark main with DW_CC_GNU_renesas_sh. -- Daniel Jacobowitz CodeSourcery From woodzltc Thu Feb 23 20:42:28 2006 From: woodzltc (Wu Zhou) Date: Thu Feb 23 20:42:28 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> Message-ID: Hi Daniel, Thanks a lot for your effort. This looks more like a proposal. :-) Regards - Wu Zhou On Thu, 23 Feb 2006, Daniel Berlin wrote: > > > > The mention of DW_TAG_entry_point along with your name suggests, in an > > unclear fashion, that you believed it to be adequate. Perhaps this is > > inaccurate, but that's at least how I read the proposal. > Well, it would be, but we'd need a flag. > [snip] > > Okay, well, let me simply edit the "proposal" (which i agree is not a > proposal) > > Most C compiler assume the main function to be "main". Other > languages might have different names, or even allow it to have > any name. If we have an entry to tell what is the main function > in a program, it will let the debugger to present this to users > in an intelligent way. Another debug-info format stabs could > support this with N_MAIN stab type. > > > Proposal: > > I propose we modify the definition of the DW_TAG_entry_point tag definition to state > that it is also usable for specifying the main entry point to a program, > not just fortran alternate entry points. > > In order to determine which of the DW_TAG_entry_point is the single main entry point to the program, > a flag attribute DW_AT_is_main(or something suitably named) should be added to the allowed attributes for DW_TAG_entry_point. > > Alternatively, we could define it as the entry_point with DW_CC_program calling convention, and delete the text that says > "The DW_CC_program value is intended to support Fortran main programs. It is not intended as a way of finding the entry address for the program." > From dberlin Thu Feb 23 20:45:06 2006 From: dberlin (Daniel Berlin) Date: Thu Feb 23 20:45:06 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <20060224043841.GA12884@nevyn.them.org> Message-ID: <1140756307.3599.49.camel@linux.site> On Thu, 2006-02-23 at 23:38 -0500, Daniel Jacobowitz wrote: > On Thu, Feb 23, 2006 at 11:08:00PM -0500, Daniel Berlin wrote: > > Proposal: > > > > I propose we modify the definition of the DW_TAG_entry_point tag > > definition to state that it is also usable for specifying the main > > entry point to a program, not just fortran alternate entry points. > > > > In order to determine which of the DW_TAG_entry_point is the single > > main entry point to the program, a flag attribute DW_AT_is_main(or > > something suitably named) should be added to the allowed attributes > > for DW_TAG_entry_point. > > If we need a new flag anyway, then why shouldn't it be a flag on > the DW_TAG_subprogram for main? That seems to me like the clearest > choice. I don't disagree, that's a fine solution as well. I was making the first and most obvious proposal to get discussion going. > > "entry point" is an overloaded term already; this isn't necessarily the > program's entry point, but the high level language's starting point. > The actual entry point will be over in _start land. Which is why it's already confusing what the heck DW_TAG_entry_point is supposed to be used for (it probably should have been named DW_TAG_alternate_entry or something). It would be nice to have an example in the next standard for what exactly it *is* used for It's apparently *none* of these things (HLL starting point, actual program entry point) that i've ever seen referred to as an "entry point". Fortran is probably the one language i never bothered to learn, but i imagine i'm not alone. > > > Alternatively, we could define it as the entry_point with > > DW_CC_program calling convention, and delete the text that says "The > > DW_CC_program value is intended to support Fortran main programs. It > > is not intended as a way of finding the entry address for the > > program." > > This isn't appropriate because it would interfere with any other > DW_AT_calling_convention that applied to the main routine - for > instance, sh-elf-gcc with -mrenesas will mark main with > DW_CC_GNU_renesas_sh. I wasn't aware anyone had extended the cc attribute. There goes that idea. From drow Thu Feb 23 20:49:42 2006 From: drow (Daniel Jacobowitz) Date: Thu Feb 23 20:49:42 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <20060224043841.GA12884@nevyn.them.org> <1140756307.3599.49.camel@linux.site> Message-ID: <20060224044935.GA13301@nevyn.them.org> On Thu, Feb 23, 2006 at 11:45:07PM -0500, Daniel Berlin wrote: > Which is why it's already confusing what the heck DW_TAG_entry_point is > supposed to be used for (it probably should have been named > DW_TAG_alternate_entry or something). > > It would be nice to have an example in the next standard for what > exactly it *is* used for Amen. It looks like someone's just added it everywhere subprograms were mentioned. > > This isn't appropriate because it would interfere with any other > > DW_AT_calling_convention that applied to the main routine - for > > instance, sh-elf-gcc with -mrenesas will mark main with > > DW_CC_GNU_renesas_sh. > > I wasn't aware anyone had extended the cc attribute. There goes that > idea. We might want to use it for things like regparm and automatic SSE usage, too. -- Daniel Jacobowitz CodeSourcery From jimb Thu Feb 23 20:53:05 2006 From: jimb (Jim Blandy) Date: Thu Feb 23 20:53:05 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> Message-ID: <8f2776cb0602232052j11a5cb33s492622fc4976e008@mail.gmail.com> On 2/23/06, Daniel Berlin wrote: > Most C compiler assume the main function to be "main". Other > languages might have different names, or even allow it to have > any name. If we have an entry to tell what is the main function > in a program, it will let the debugger to present this to users > in an intelligent way. Another debug-info format stabs could > support this with N_MAIN stab type. > > > Proposal: > > I propose we modify the definition of the DW_TAG_entry_point tag definition to state > that it is also usable for specifying the main entry point to a program, > not just fortran alternate entry points. > > In order to determine which of the DW_TAG_entry_point is the single main entry point to the program, > a flag attribute DW_AT_is_main(or something suitably named) should be added to the allowed attributes for DW_TAG_entry_point. I think reusing tags this way is not a great idea. In Fortran, an entry point is a very specific language feature that one can attach to a subprogram. "An ENTRY statement establishes an alternate entry point for an external subprogram or a module subprogram," says one language reference I found on the web So DW_TAG_entry_point in Dwarf describes an "ENTRY" statement in Fortran, just as DW_TAG_try_block describes a "try" block in Java. When similar features occur in languages, I think it makes very good sense to use the same Dwarf tag to describe them all. It's nice to use DW_TAG_subprogram for both C functions and Pascal procedures and functions, for example. But it seems to me that Fortran subprogram entry points and the 'main function' of an overall executable are not sufficiently analogous to merit this kind of reuse. The fact that it might be necessary to have an attribute saying which sort of use is at hand reinforces my misgivings. Also --- in Java, if I remember correctly, it's not clear when you compile a class whether that class is going to be the program's entry point or not. You need to pass a '--main=CLASSNAME' option to GCJ, for example, to say that the 'main' method of the class named CLASS will be the program's entry point. So the compiler can't emit a DW_TAG_entry_point child of the 'main' method as required by the proposal, since the entry point hasn't been chosen yet. I'd prefer adding a new attribute, DW_AT_program_entry_point, whose value would be a reference to the die representing the program's main function. This would be an attribute of some DW_TAG_compile_unit die. It wouldn't necessarily need to refer to a die in that compilation unit, so gcj could emit a dummy Dwarf compilation unit just to contain the DW_AT_program_entry_point attribute at link time. I'm shaky on the linking procedure for Java, so corrections and clarifications are welcome, as always. From jeff.nelson Thu Feb 23 23:11:17 2006 From: jeff.nelson (jeff nelson) Date: Thu Feb 23 23:11:17 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <8f2776cb0602232052j11a5cb33s492622fc4976e008@mail.gmail.com> Message-ID: <1140765054.9894.8.camel@localhost.localdomain> On Thu, 2006-02-23 at 20:52 -0800, Jim Blandy wrote: > ...the compiler can't emit a > DW_TAG_entry_point child of the 'main' method as required by the > proposal, since the entry point hasn't been chosen yet. This is a good point. I know of at least one COBOL implementation where any number of routines could be the program "main". The linker is the one that makes the choice. > I'd prefer adding a new attribute, DW_AT_program_entry_point, whose > value would be a reference to the die representing the program's main > function. This would be an attribute of some DW_TAG_compile_unit die. > It wouldn't necessarily need to refer to a die in that compilation > unit, so gcj could emit a dummy Dwarf compilation unit just to contain > the DW_AT_program_entry_point attribute at link time. I like this suggestion the best so far. -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freestandards.org/pipermail/dwarf-discuss/attachments/20060224/3e061995/attachment.htm From john.e.bishop Fri Feb 24 08:21:54 2006 From: john.e.bishop (Bishop, John E) Date: Fri Feb 24 08:21:54 2006 Subject: [Dwarf-discuss] RE: Dwarf-discuss Digest, Vol 17, Issue 2 [bname of the main routine] Message-ID: <5404AEB459F8354F81995E038F34320002822836@hdsmsx401.amr.corp.intel.com> > If we need a new flag anyway, then why shouldn't it be a flag on > the DW_TAG_subprogram for main? I agree. Entry points are used for Fortran alternate entry points (a terrible language feature, perhaps, but it's part of the language). The body of a subroutine is shared by different signatures, so you can call it in different ways. Here's an example: "bar" is the main subroutine, "foo" is an alternate entry point: subroutine bar(I,J,K,I1) INTEGER*4 I,J,K,L,I1 integer*4 A /0 0/ real*4 C /0.0/ write (6,*) 'Entered via bar: ', i, j, k write (6,*) '*****************************' goto 1000 entry foo(J,K,L,I1) write (6,*) 'Entered via foo: ', j, k, l, I1 write (6,*) '*****************************' 200 a = j goto 1000 1000 write (6,*) 'Exiting bar & all its entry points' write (6,*) 'A=', a write (6,*) 'C=', c write (6,*) 'Bye!' return end -John Bishop (intel debugger project) From eager Fri Feb 24 09:30:30 2006 From: eager (Michael Eager) Date: Fri Feb 24 09:30:30 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> Message-ID: <43FF42A1.5080205@eagercon.com> It's probably better to move this to the DWARF Workgroup mailing list. The discussion list is for questions about DWARF; the workgroup list is for DWARF development. I'm ccing Dwarf-discuss, but future discussion should be on the workgroup mailing list. I have a couple philosophical suggestions, a few questions, and some comments about the proposal. Suggestions: Tags distinguish different kinds of things (e.g., DW_TAG_FISH and DW_TAG_DOG), while attributes describe features of these things and may be applied to different tags if appropriate (e.g., DW_AT_SMALL, DW_AT_WHITE, DW_AT_SHORT_TAIL, DW_AT_FINS). If what you want to describe is a feature or quality which distinguishes one item of a class from another, which are otherwise the same, then create an attribute to describe this difference. If you are describing something new and different, then create a new tag. (We haven't always followed this principle closely, for a variety of reasons, so there are parts of the DWARF spec where things which are very similar, like structure and class, have different tags.) Keep tag and attribute meanings pure and consistent, independent of the context in which they are used. Don't reuse a tag or attribute to mean different things. It's OK to expand the scope where a tag or attribute is used to address new languages or features. Draft proposals so that there is one recommendation on the table. Proposals which are "we could to this, or we could do that, or we could do the other" are much less clear than "this is the problem; this is the solution". Get the discussion out on the floor and thrashed out before drafting a proposal. Questions: This proposal only mentions C, and says that it isn't needed for this language. (C++ and Java have no need.) What languages need this extension? Is it always possible for the compiler for these languages to identify the "main" function, or is this sometimes done by a linker or loader? Are there other means for identifying this information? For example, how does the program loader know where the "main" function is, or does it need to know? What is done currently to address this situation? My memory of Fortran is antediluvian, but I thought that entry points were unrelated to which function was the "main" function. I thought that they were a means to combine similar code together with two different function names, like sin() and cos(). A "main" function in Fortran doesn't need to have an alternate entry point. What do Ada, Cobol, or other languages do to specify the "main" function? Comments about the proposal: It seems to me that if this information is needed, then this should be an attribute (say, DW_AT_main) which can be used with DW_TAG_subprogram, perhaps with the restriction that only one such attribute may be present in a program. Repurposing DW_TAG_entry_point or DW_CC_program to mean something different isn't a good idea. See suggestion #2 above. A clear statement of the problem you are trying to address goes a long way to support your proposal. The problem statement here is less than clear. Mentioning that C doesn't need this or stabs has N_MAIN adds little to clarify this. If the question is "what's the problem?", then creating yet more possible solutions isn't the answer. (Put yourself into the position of looking at this proposal a year from now. It's much easier to understand if the proposal is concise and clear, than if it requires you to remember the circumstances when it was made or to try to infer the problem from the proposed solution.) Daniel Berlin wrote: > On Thu, 2006-02-23 at 19:40 -0800, Michael Eager wrote: > >>Daniel Berlin wrote: >> >>>On Thu, 2006-02-23 at 18:55 -0800, Michael Eager wrote: >>> >>> >>>>Wu Zhou wrote: >>>> >>>> >>>>>Hello, committee members >>>>> >>>>>Now that DWARF-3 had been published for a while, can I have the pleasure >>>>>to re-open this deferred issue? >>>>> >>>>>I don't see any action I can do from the net. So I am asking here. >>>>> >>>>>Regards >>>>>- Wu Zhou >>>> >>>>http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed >>>> >>>>We will consider revisions to the DWARF standard starting mid-year. >>>> >>>>The proposal is somewhat vague. I'm personally unclear >>>>why there is a need for an new TAG. Saying Stabs does something >>>>one way so DWARF should do the same is not persuasive. >>>> >>>>Is there a reason why using DW_TAG_entry_point doesn't work? >>> >>> >>>DW_TAG_entry_point was very specifically pointed out to *not* be the >>>same as what he is looking for, IIRC. >> >>As I indicated, the proposal is vague. Also short. >> >>The mention of DW_TAG_entry_point along with your name suggests, in an >>unclear fashion, that you believed it to be adequate. Perhaps this is >>inaccurate, but that's at least how I read the proposal. > > Well, it would be, but we'd need a flag. > > > > >>>>In general, proposals which have been implemented are preferred. >>> >>>We specifically put off adding it to GCC to get resolution *first*, so >>>this is kinda a downer. Why create the chance that someone will do this >>>again a different way, when this is a simple issue that could be >>>resolved once, first? >>> >>>This is not something we need heavy implementation experience to determine >>>whether it is useful or not. >>>But I guess for now, Wu, DW_TAG_GNU_entry_point or whatever should be added. >> >>Again, this is a general principle. Unless there is a clear >>proposal (which this is not) then the preference is for some >>demonstration that the proposed change actually addresses >>the issue. >> >>Again, I read the very few lines of the proposal and I don't >>find it clear. Perhaps making a clear and complete proposal >>would be a more productive way to get a resolution. > > > Okay, well, let me simply edit the "proposal" (which i agree is not a > proposal) > > Most C compiler assume the main function to be "main". Other > languages might have different names, or even allow it to have > any name. If we have an entry to tell what is the main function > in a program, it will let the debugger to present this to users > in an intelligent way. Another debug-info format stabs could > support this with N_MAIN stab type. > > > Proposal: > > I propose we modify the definition of the DW_TAG_entry_point tag definition to state > that it is also usable for specifying the main entry point to a program, > not just fortran alternate entry points. > > In order to determine which of the DW_TAG_entry_point is the single main entry point to the program, > a flag attribute DW_AT_is_main(or something suitably named) should be added to the allowed attributes for DW_TAG_entry_point. > > Alternatively, we could define it as the entry_point with DW_CC_program calling convention, and delete the text that says > "The DW_CC_program value is intended to support Fortran main programs. It is not intended as a way of finding the entry address for the program." > > > > > -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 From eager Fri Feb 24 11:29:26 2006 From: eager (Michael Eager) Date: Fri Feb 24 11:29:26 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <20060224043841.GA12884@nevyn.them.org> <1140756307.3599.49.camel@linux.site> Message-ID: <43FF5E82.30804@eagercon.com> Daniel Berlin wrote: > Which is why it's already confusing what the heck DW_TAG_entry_point is > supposed to be used for (it probably should have been named > DW_TAG_alternate_entry or something). While there's not a lot of explanation, I think that the DWARF standard is explicit: DW_TAG_entry_point is a Fortran alternate entry point. Any other use for this tag does not follow the standard. > It would be nice to have an example in the next standard for what > exactly it *is* used for > > It's apparently *none* of these things (HLL starting point, actual > program entry point) that i've ever seen referred to as an "entry > point". Fortran is probably the one language i never bothered to learn, > but i imagine i'm not alone. It's a Fortran-specific feature, as the DWARF standard says. As Jim Blandy said, the tag is a specific mapping to a specific language feature and the name is based on this feature name. It's a "term of art" in the Fortran language. The fact that you are not familiar with this language is not a very compelling reason for changing it's name or giving it a different meaning. Sorry. As for examples, I would certainly like to see a document which provides recommended language bindings for DWARF. This has been something that we've wanted for many years. It's also a lot of work. Feel free to volunteer. :-) >>>Alternatively, we could define it as the entry_point with >>>DW_CC_program calling convention, and delete the text that says "The >>>DW_CC_program value is intended to support Fortran main programs. It >>>is not intended as a way of finding the entry address for the >>>program." >> >>This isn't appropriate because it would interfere with any other >>DW_AT_calling_convention that applied to the main routine - for >>instance, sh-elf-gcc with -mrenesas will mark main with >>DW_CC_GNU_renesas_sh. > > > I wasn't aware anyone had extended the cc attribute. There goes that > idea. Extending the DW_CC attribute is entirely appropriate. If there are multiple ways to call a subroutine, then this attribute describes what ways apply to the routine. The DWARF spec defines three generic calling conventions. The spec also defines a user extension range for additional calling conventions. (I hope that DW_CC_GNU_renesas_sh is in this user extension range.) Calling conventions seem unrelated to the question (if I understand it correctly) of where the program starts. In C/C++, the calling convention for main() is no different from any other function. If you are proposing an extension to DWARF to support some specific language feature (a question which I don't think has been answered) then then an understanding of that language would be advisable. -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 From dberlin Fri Feb 24 15:26:10 2006 From: dberlin (Daniel Berlin) Date: Fri Feb 24 15:26:10 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <20060224043841.GA12884@nevyn.them.org> <1140756307.3599.49.camel@linux.site> <43FF5E82.30804@eagercon.com> Message-ID: <1140823550.2557.24.camel@linux.site> On Fri, 2006-02-24 at 11:29 -0800, Michael Eager wrote: > Daniel Berlin wrote: > > > Which is why it's already confusing what the heck DW_TAG_entry_point is > > supposed to be used for (it probably should have been named > > DW_TAG_alternate_entry or something). > > While there's not a lot of explanation, I think that the DWARF > standard is explicit: DW_TAG_entry_point is a Fortran alternate > entry point. Any other use for this tag does not follow the standard. > > > It would be nice to have an example in the next standard for what > > exactly it *is* used for > > > > It's apparently *none* of these things (HLL starting point, actual > > program entry point) that i've ever seen referred to as an "entry > > point". Fortran is probably the one language i never bothered to learn, > > but i imagine i'm not alone. > > It's a Fortran-specific feature, as the DWARF standard says. > As Jim Blandy said, the tag is a specific mapping to a specific > language feature and the name is based on this feature name. > It's a "term of art" in the Fortran language. And is also a term of art in general compilers, linkers, loaders, and debuggers. I would wager a large amount of money that out of these groups of people, 90% think of entry point as something *other than this 'fortran term of art'* That is why i proposed to rename it. > The fact that you are > not familiar with this language is not a very c > ompelling reason forchanging it's name or giving it a different meaning. Sorry. Whatever Michael, this issue is a side issue anyway. I only made it part of a formal proposal so that you would stop saying we should implement it first, then come back and make a proposal, and because I believe that generating discussion will lead to the right answer (and it seems to have). I'm sure you will respond that we don't have enough information to generate discussion, or something of the sort. > >>>Alternatively, we could define it as the entry_point with > >>>DW_CC_program calling convention, and delete the text that says "The > >>>DW_CC_program value is intended to support Fortran main programs. It > >>>is not intended as a way of finding the entry address for the > >>>program." > >> > >>This isn't appropriate because it would interfere with any other > >>DW_AT_calling_convention that applied to the main routine - for > >>instance, sh-elf-gcc with -mrenesas will mark main with > >>DW_CC_GNU_renesas_sh. > > > > > > I wasn't aware anyone had extended the cc attribute. There goes that > > idea. > > Extending the DW_CC attribute is entirely appropriate. > If there are > multiple ways to call a subroutine, then this attribute describes what > ways apply to the routine. The DWARF spec defines three generic calling > conventions. The spec also defines a user extension range for additional > calling conventions. (I hope that DW_CC_GNU_renesas_sh is in this > user extension range.) > > Calling conventions seem unrelated to the question (if I understand > it correctly) of where the program starts. In C/C++, the calling > convention for main() is no different from any other function. > If you are proposing an extension to DWARF to support some specific > language feature (a question which I don't think has been answered) In some cases it is a specific language feature, in other some, it's generally a feature of the compilers and OSen to provide some sort of name for the main function that the user has intended to be the subroutine run when the program is started. Some languages (like Ada) do actually allow you to explicitly specify the name of the main function, However, some just allow almost anything defined properly to be a main function. GCJ, for example, is a java compiler generating static executables. Java allows anything with a static main method to be run as the main program. To support this, gcj has a --main option that specifies which class's main method should be run on startup. However, the method named "main" (or whatever the ABI in question specifies) that gcj generates, and the OS runs, is *not* the one the user specified. It is a stub that does a bunch of initialization, and then calls the one the user specified. Unlike in C, where this is generally hidden in something like __start, it's not hidden in GCJ generated executables, so the first thing the user ends up debugging is some compiler generated routine that they have no source to, instead of the routine *they specified as main*. This was the original purpose of the N_MAIN extension in STABS, to specify what routine the user had said main was, or the language said main was, so that if you step into a program, you go to the method the user expected to be run, instead of compiler generated code. From jimb Fri Feb 24 15:57:39 2006 From: jimb (Jim Blandy) Date: Fri Feb 24 15:57:39 2006 Subject: [Dwarf-workgroup] Re: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <20060224043841.GA12884@nevyn.them.org> <1140756307.3599.49.camel@linux.site> <43FF5E82.30804@eagercon.com> <1140823550.2557.24.camel@linux.site> Message-ID: <8f2776cb0602241557o425de073m1264e9a8ee9f2dbe@mail.gmail.com> Folks, this is a collegial discussion. Let's save sarcasm for people who are actually ill-intentioned; I don't think we have any such here. This originally seemed like a straightforward problem to me, so like Daniel I was disappointed that there was as much discussion as there has been (even as I contributed to expanding the discussion). But I think it's more subtle than we first realized: - We have the issue of the name of the Fortran ENTRY tag; while the spec is clear what the tag refers to, it's also true that 'entry point' has different well-recognized meanings in nearby areas, so it's not a good name. I don't think renaming the tag is worth it, but I also think DW_TAG_alternate_entry_point would have been better. - There's the question of making sure the information is practical to generate. In cases where the entry point is only chosen after most of the compilation is finished, it's not reasonable to expect the linker to go through and re-jigger the main function's CU's Dwarf info to add a new die or attribute. - Ron brings up a bunch of good questions about what we really mean by 'entry point' anyway. In light of all that, I think Michael's suggestion that we back off and explain how debuggers actually use the information is reasonable. GDB uses the main name to decide where to end backtraces. GDB has options to show the entire backtrace, including the entry point function provided by the system run-time files (like crt0.s), but by default it restricts the backtrace to the user's own code; main's is the bottom frame on the stack. It used to do this simply by looking for a function named "main", but this doesn't work well for languages other than C and C++. I believe N_MAIN was added for Java. GDB also uses the main name for its 'start' command, which basically starts the program and lets it run to the beginning of 'main'. This has the same problems as the previous application: for Java, it's clear what you'd like the 'start' command to do, but GDB doesn't have enough information to dope it out on its own. GDB uses it to select a default start position for the 'list' command, which lists source code: if you start up GDB and type 'list', you'll get the code for 'main'. Again, in Java, it's clear what GDB ought to do, but it doesn't have enough information to do it. Some C++ implementations actually have 'main' call an internal function '__main', which does all the C++ constructors needed at startup time. GDB uses the 'main' name to recognize these calls and skip over them transparently. This seems like a questionable use, to me; I don't think Dwarf should go out of its way to make sure this works. From dberlin Fri Feb 24 16:20:05 2006 From: dberlin (Daniel Berlin) Date: Fri Feb 24 16:20:05 2006 Subject: [Dwarf-workgroup] Re: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <20060224043841.GA12884@nevyn.them.org> <1140756307.3599.49.camel@linux.site> <43FF5E82.30804@eagercon.com> <1140823550.2557.24.camel@linux.site> <8f2776cb0602241557o425de073m1264e9a8ee9f2dbe@mail.gmail.com> Message-ID: <1140826805.29907.15.camel@linux.site> On Fri, 2006-02-24 at 15:57 -0800, Jim Blandy wrote: > Folks, this is a collegial discussion. Let's save sarcasm for people > who are actually ill-intentioned; I don't think we have any such here. > > This originally seemed like a straightforward problem to me, so like > Daniel I was disappointed that there was as much discussion as there > has been (even as I contributed to expanding the discussion). > > But I think it's more subtle than we first realized: > > - We have the issue of the name of the Fortran ENTRY tag; while the > spec is clear what the tag refers to, it's also true that 'entry > point' has different well-recognized meanings in nearby areas, so it's > not a good name. I don't think renaming the tag is worth it, but I > also think DW_TAG_alternate_entry_point would have been better. Realize that renaming the tag almost has no cost, IMHO, only the cost to say it was renamed. None of the *consumers* actually care about the name, only the number it represents, so it doesn't really introduce compatibility problems. I will finally note that it has been confusing people other than me since at least 2003. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1427#c8 (There are a bunch of other bugs in which other people get confused about what DW_TAG_entry_point is supposed to be for). I'll leave this one alone now, however. > > - There's the question of making sure the information is practical to > generate. In cases where the entry point is only chosen after most of > the compilation is finished, it's not reasonable to expect the linker > to go through and re-jigger the main function's CU's Dwarf info to add > a new die or attribute. > > - Ron brings up a bunch of good questions about what we really mean by > 'entry point' anyway. :P > In light of all that, I think Michael's suggestion that we back off > and explain how debuggers actually use the information is reasonable. > > GDB uses the main name to decide where to end backtraces. GDB has > options to show the entire backtrace, including the entry point > function provided by the system run-time files (like crt0.s), but by > default it restricts the backtrace to the user's own code; main's is > the bottom frame on the stack. > > It used to do this simply by looking for a function named "main", but > this doesn't work well for languages other than C and C++. I believe > N_MAIN was added for Java. I believe it was actually added to *STABS* for Modula-2, way the heck back in the day. But GDB support was indeed added for gcj's purposes. http://sourceware.org/ml/gdb-patches/2000-q1/msg00527.html (Note the followup, "I looked over that patch and the basic concept looks fine. N_MAIN is already documented in doc/stabs.texinfo.") > > GDB also uses the main name for its 'start' command, which basically > starts the program and lets it run to the beginning of 'main'. This > has the same problems as the previous application: for Java, it's > clear what you'd like the 'start' command to do, but GDB doesn't have > enough information to dope it out on its own. > > GDB uses it to select a default start position for the 'list' command, > which lists source code: if you start up GDB and type 'list', you'll > get the code for 'main'. Again, in Java, it's clear what GDB ought to > do, but it doesn't have enough information to do it. At least, in DWARF2/3 it does not. > > Some C++ implementations actually have 'main' call an internal > function '__main', which does all the C++ constructors needed at > startup time. GDB uses the 'main' name to recognize these calls and > skip over them transparently. This seems like a questionable use, to > me; I don't think Dwarf should go out of its way to make sure this > works. > From dberlin Fri Feb 24 18:26:18 2006 From: dberlin (Daniel Berlin) Date: Fri Feb 24 18:26:18 2006 Subject: [Dwarf-workgroup] Re: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <43FF42A1.5080205@eagercon.com> <43FF7BDE.9080805@charter.net> Message-ID: <1140834374.29907.53.camel@linux.site> On Fri, 2006-02-24 at 16:34 -0500, Ron Brender wrote: > There are several intermingling issues here, unfortunately. > > Some languages are quite explicit about what routine is the main routine > of a program. A compiler can mark it so. Ada comes to mind. > > Other languages are quite explit about whether any particular routine > can validly be a main routine. But there may be multiple such in a > program and the actual main routine is detemined in some other way > (linker option, first encounted, ?). COBOL comes to mind. > > Some languages may have code that must be executed prior to the code of > the main program. C++ constructors come to mind? In this case is the > "logical" main routine of interest, or the "real" main routine (of > constructors) of interest? Or sometimes both? At least in GDB's case, the functionality it used the STABS N_MAIN "stab" for only wanted to discover the logical main routine of interest (for the reasons Jim described). I'm loathe to believe we should try to come up with an all encompassing solution when the functionality of N_MAIN (IE find the logical main routine) is all the debugger users I've met have been clamoring for. :) Thinking from the consumer perspective, I don't believe there is anything useful i could provide my users that we do not already if you also told me where the "real" main routine was. > > Some environments can have "main" entry points in shared images that act > as main routines iff the image is activated as a "main image". I was afraid you would point this out. Are these environments still around? The last one I remember was BeOS, which is quite clearly dead :) > Is such a > "conditional main routine" that same as or different than a main routine > as defined above, or something else? It would probably have to fall into the category of the above. It would be up to the consumer to determine what the program they are running is, and thus, what image it should be looking at to find the "logical main" routine. > > I expect that are other variations that escape me at the moment. > Additions to this taxonomy are certainly invited. > > Useful insight might also be found by asking for examples where debugger > implementors are troubled by having to incorporate environment specific > knowledge and methods that they would rather not get involved in. > > In any case, it seems clear to me that DWARF constructs, which are > inherently a compiler created descriptive mechanism, are at best only a > part of the overall descriptive problem. The question is what additional > DWARF information can be helpful enough to be useful often enough to be > worthwhile incorporating in the DWARF format. This is where I believe the answer is clear. I don't believe consumers could use information *other* than something (be it attribute, tag, or bright yellow costume) to tell them the logical main routine, often enough that we should worry about it. At least, nobody has requested more from ibm's compilers/debuggers, or gcc/gdb. --Dan From drow Fri Feb 24 20:43:13 2006 From: drow (Daniel Jacobowitz) Date: Fri Feb 24 20:43:13 2006 Subject: [Dwarf-workgroup] Re: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <43FF42A1.5080205@eagercon.com> <43FF7BDE.9080805@charter.net> <1140834374.29907.53.camel@linux.site> Message-ID: <20060225044259.GA14089@nevyn.them.org> On Fri, Feb 24, 2006 at 09:26:14PM -0500, Daniel Berlin wrote: > On Fri, 2006-02-24 at 16:34 -0500, Ron Brender wrote: > > Some environments can have "main" entry points in shared images that act > > as main routines iff the image is activated as a "main image". > > I was afraid you would point this out. > Are these environments still around? > > The last one I remember was BeOS, which is quite clearly dead :) You can do this in ELF, so yes. Run /lib/libc.so.6 on a GNU/Linux system, for instance. > > Is such a > > "conditional main routine" that same as or different than a main routine > > as defined above, or something else? > > It would probably have to fall into the category of the above. It would > be up to the consumer to determine what the program they are running is, > and thus, what image it should be looking at to find the "logical main" > routine. Yes, I think that's reasonable. But this bit doesn't really apply to the ELF implementations I am familiar with, since they can have ELF entry points, but generally do not have a standard "main" function. -- Daniel Jacobowitz CodeSourcery From Chris.Quenelle Tue Feb 28 17:43:16 2006 From: Chris.Quenelle (Chris Quenelle) Date: Tue Feb 28 17:43:16 2006 Subject: [Dwarf-discuss] DWARF Issue 050808.2&body=Re: References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <20060224043841.GA12884@nevyn.them.org> <1140756307.3599.49.camel@linux.site> Message-ID: <4404FC14.1080908@sun.com> Daniel Berlin wrote: > It would be nice to have an example in the next standard for what > exactly it *is* used for (I haven't finished catching up on dwarf email, so I don't know if this has been answered yet) The existing 'entry' tag is for recording an entry point name and a set of parameters ("dummy arguments" in fortran) and their types. Here is an example: subroutine sub(num) integer num integer j j=num 10 write(*,*) j go to 20 entry sub1(num1) j=num1+num1 20 j=j-1 if ( j .eq. 0) return go to 10 end All of this code is one "function" and should be described by one DW_TAG_subprogram tag. Does that help? You are right, it would have been more clear to call the tag DW_TAG_alternate_entry_point, since it has similar information to a DW_TAG_subprogram tag, but without being allowed to contain many things that a subprogram contains. --chris From Chris.Quenelle Tue Feb 28 17:52:38 2006 From: Chris.Quenelle (Chris Quenelle) Date: Tue Feb 28 17:52:38 2006 Subject: [Dwarf-discuss] DW_AT_program_entry_point In-Reply-To: <8f2776cb0602232052j11a5cb33s492622fc4976e008@mail.gmail.com> References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <8f2776cb0602232052j11a5cb33s492622fc4976e008@mail.gmail.com> Message-ID: <4404FE51.1010503@sun.com> Jim Blandy: > I'd prefer adding a new attribute, DW_AT_program_entry_point, whose > value would be a reference to the die representing the program's main > function. This would be an attribute of some DW_TAG_compile_unit die. > It wouldn't necessarily need to refer to a die in that compilation > unit, so gcj could emit a dummy Dwarf compilation unit just to contain > the DW_AT_program_entry_point attribute at link time. I like this better than reusing the existing entry_point tag. But I don't think it's appropriate to attach it to the CU tag. It should be an attribute of the DW_TAG_subprogram that represents the 'main'-ish function. Nobody is going to scan all the CU tags and look for special attributes. That's what the index tables are for. Ideally this would be an attribute of the DIE that represents the main program, but we don't have a DIE for that and are unlikely to grow one in the near future unless the linker starts reading and writing dwarf. I believe it is common practice when scanning the index lists to read the attributes of the DIE's that are indexed, and so an attribute of the subprogram die would be found and remembered at that time. --chris From brian.nettleton Tue Feb 28 18:37:34 2006 From: brian.nettleton (Nettleton, Brian) Date: Tue Feb 28 18:37:34 2006 Subject: [Dwarf-discuss] DW_AT_program_entry_point Message-ID: <205D614FB7B84C468726248150BC46AE1A3B29@ala-mail04.corp.ad.wrs.com> > -----Original Message----- > From: dwarf-discuss-bounces at lists.freestandards.org > [mailto:dwarf-discuss-bounces at lists.freestandards.org] On > Behalf Of Chris Quenelle > Sent: Tuesday, February 28, 2006 5:52 PM > To: Jim Blandy > Cc: DWARF-DISCUSS at freestandards.org > Subject: [Dwarf-discuss] DW_AT_program_entry_point > [snip] > > I believe it is common practice when scanning the index > lists to read the attributes of the DIE's that are > indexed, and so an attribute of the subprogram die > would be found and remembered at that time. > I'm not sure about common practice or not but our Eclipse based debugger doesn't do this. We don't do much scanning at all and take a much more lazy design approach (i.e. we prefer to collect information when it's asked for). So we much prefer "global" entries which are easy to find for such program-wide information. -Brian Nettleton Wind River Systems From Chris.Quenelle Tue Feb 28 18:44:47 2006 From: Chris.Quenelle (Chris Quenelle) Date: Tue Feb 28 18:44:47 2006 Subject: [Dwarf-discuss] DW_AT_program_entry_point In-Reply-To: <205D614FB7B84C468726248150BC46AE1A3B29@ala-mail04.corp.ad.wrs.com> References: <205D614FB7B84C468726248150BC46AE1A3B29@ala-mail04.corp.ad.wrs.com> Message-ID: <44050A8E.7070401@sun.com> > I'm not sure about common practice or not but our Eclipse based debugger > doesn't do this. We don't do much scanning at all and take a much more > lazy design approach (i.e. we prefer to collect information when it's > asked for). So we much prefer "global" entries which are easy to find > for such program-wide information. I stand corrected. --chris From jimb Tue Feb 28 20:51:03 2006 From: jimb (Jim Blandy) Date: Tue Feb 28 20:51:03 2006 Subject: [Dwarf-discuss] Re: DW_AT_program_entry_point In-Reply-To: <4404FE51.1010503@sun.com> References: <43FE7590.6010000@eagercon.com> <1140750905.3599.23.camel@linux.site> <43FE8017.9040309@eagercon.com> <1140754080.3599.41.camel@linux.site> <8f2776cb0602232052j11a5cb33s492622fc4976e008@mail.gmail.com> <4404FE51.1010503@sun.com> Message-ID: <8f2776cb0602282050m1c916442jc0f56bb1e7e91545@mail.gmail.com> On 2/28/06, Chris Quenelle wrote: > Nobody is going to scan all the CU tags and look for special > attributes. That's what the index tables are for. > Ideally this would be an attribute of the DIE that > represents the main program, but we don't have a DIE for > that and are unlikely to grow one in the near future unless > the linker starts reading and writing dwarf. I hadn't read this message when I sent my last reply. Sorry about that. GDB does happen to scan all the CU tags, but it's considered a design flaw, not a feature, that it doesn't make better use of Dwarf's indexes.