From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Bryce McKinlay Cc: gdb@sourceware.cygnus.com, java-discuss@sourceware.cygnus.com Subject: Re: Status of Linuxthreads support in gdb 4.18? Date: Wed, 28 Jul 1999 08:57:00 -0000 Message-id: References: <379EA3DB.58B72C0A@albatross.co.nz> X-SW-Source: 1999-q3/msg00112.html > Can anyone say what is the current status of support for Threads on > Linux in gdb 4.18? It don't exist. I added it to our Code Fusion product, and now I have to find time to merge it into our main sources. >From jimb@cygnus.com Wed Jul 28 13:33:00 1999 From: Jim Blandy To: Sekaran Nanja Cc: Rajiv Mirani , Mike Vermeulen , gdb@sourceware.cygnus.com Subject: Re: Regarding Range Table Date: Wed, 28 Jul 1999 13:33:00 -0000 Message-id: References: <37990D39.B393D61B@cup.hp.com> <379CCBBD.6E3FC2F3@cup.hp.com> <379D1B3A.32B9121B@cup.hp.com> X-SW-Source: 1999-q3/msg00113.html Content-length: 2180 > Jim>It makes more sense to me to add your new info to the struct symbol > Jim>itself, so that value_of_variable can check it and complain > Jim>appropriately. It would be nice to do it in a way which doesn't use > Jim>much space if we don't have this kind of information for the symbol. > > Jim>What do you think? Sekaran> Yes. It makes sense to add this info. to struct symbol to Sekaran> keep things clean but we lose the new info. for an alias Sekaran> symbol containing multiple ranges (Ex: variable has the same Sekaran> home in several distinct ranges.). I think it is better to Sekaran> save these new info. in range_list struct. Please let me know Sekaran> what do you think about this. Oh, I see --- just as a given variable home is valid only in certain code ranges, your critical assignment motion info applies only to certain code ranges. And the ranges for a critical assignment motion record will usually be some arbitrary subset of the variable's home's ranges. So a structure like this would be sufficient: struct symbol { ... contains address class and symbol value ... struct range_list *ranges; ... }; struct range_list { CORE_ADDR start, end; unsigned int set_early : 1; unsigned int set_late : 1; unsigned int unknown : 1; int comes_from_line; int moved_to_line; struct range_list *next; }; Is that enough to accurately represent all the information you have? Does it seem to be a straightforward representation, or is it obscure? Is it possible for both set_early and set_late to be true for a given range? It seems to me that set_late means that the variable is dead, while set_early means that the variable is live, but not live in the way one would expect from reading the source. Aren't set_early, set_late, and unknown all mutually exclusive conditions? If that's true, they should be represented with an enum, not as separate bits. I think comes_from_line and moved_to_line should be CORE_ADDR's, not line numbers. The mapping between source location and code is already represented elsewhere; we shouldn't mix it in here if we don't have to. We should convert them into line numbers when they are output. >From snanja@cup.hp.com Wed Jul 28 14:48:00 1999 From: Sekaran Nanja To: Jim Blandy Cc: Rajiv Mirani , Mike Vermeulen , gdb@sourceware.cygnus.com Subject: Re: Regarding Range Table Date: Wed, 28 Jul 1999 14:48:00 -0000 Message-id: <379F7A7F.8A21C4D2@cup.hp.com> References: <37990D39.B393D61B@cup.hp.com> <379CCBBD.6E3FC2F3@cup.hp.com> <379D1B3A.32B9121B@cup.hp.com> X-SW-Source: 1999-q3/msg00114.html Content-length: 3340 >>Is that enough to accurately represent all the information you have? >>Does it seem to be a straightforward representation, or is it obscure? Yes. This is what I have already started implementing. >>Is it possible for both set_early and set_late to be true for a given >>range? No. >> Aren't set_early, >>set_late, and unknown all mutually exclusive conditions? Yes. >>If that's >>true, they should be represented with an enum, not as separate bits. Yes. I agree. >>I think comes_from_line and moved_to_line should be CORE_ADDR's, not >>line numbers. The mapping between source location and code is already >>represented elsewhere; we shouldn't mix it in here if we don't have >>to. We should convert them into line numbers when they are output. I think either CODE_ADDR or line number is fine for this information. Since HP debug info. format saves this info. as line number, it is preferable to save this info. as line number so that additional processing is not required for both saving as well as displaying. Thanks, Sekaran. Jim Blandy wrote: > > Jim>It makes more sense to me to add your new info to the struct symbol > > Jim>itself, so that value_of_variable can check it and complain > > Jim>appropriately. It would be nice to do it in a way which doesn't use > > Jim>much space if we don't have this kind of information for the symbol. > > > > Jim>What do you think? > > Sekaran> Yes. It makes sense to add this info. to struct symbol to > Sekaran> keep things clean but we lose the new info. for an alias > Sekaran> symbol containing multiple ranges (Ex: variable has the same > Sekaran> home in several distinct ranges.). I think it is better to > Sekaran> save these new info. in range_list struct. Please let me know > Sekaran> what do you think about this. > > Oh, I see --- just as a given variable home is valid only in certain > code ranges, your critical assignment motion info applies only to > certain code ranges. And the ranges for a critical assignment motion > record will usually be some arbitrary subset of the variable's home's > ranges. > > So a structure like this would be sufficient: > > struct symbol { > ... contains address class and symbol value ... > struct range_list *ranges; > ... > }; > > struct range_list { > CORE_ADDR start, end; > > unsigned int set_early : 1; > unsigned int set_late : 1; > unsigned int unknown : 1; > > int comes_from_line; > int moved_to_line; > > struct range_list *next; > }; > > Is that enough to accurately represent all the information you have? > Does it seem to be a straightforward representation, or is it obscure? > > Is it possible for both set_early and set_late to be true for a given > range? It seems to me that set_late means that the variable is dead, > while set_early means that the variable is live, but not live in the > way one would expect from reading the source. Aren't set_early, > set_late, and unknown all mutually exclusive conditions? If that's > true, they should be represented with an enum, not as separate bits. > > I think comes_from_line and moved_to_line should be CORE_ADDR's, not > line numbers. The mapping between source location and code is already > represented elsewhere; we shouldn't mix it in here if we don't have > to. We should convert them into line numbers when they are output.