This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > > In message <r2lnu8tsl2.fsf@happy.cygnus.com>you write: > > Jeffrey A Law <law@cygnus.com> writes: > > > > > Can you show me the code which produced that kind of stab? In > > > particular there's two symbols "lose" and "_dl_map_object_from_fd" > > > after the type "(0,19)". The only way that can happen is for nested > > > functions as far as I know. > > > > These are nested functions indeed. See elf/dl-load.c in the glibc tree. > OK. It makes sense now; I must admit I'm a little suprised to see > a nested function in the glibc sources. > > > Anyway, this line at the end of define_symbol > > while (*p && (*p == ';' || *p == ',')) > > I think needs to be changed to: > > while (*p && *p == ';') > > I'm not sure why the original code allowed a comma -- it's clearly > not allowed by the LRS specs: > > <ref> - "#id" where "#id" refers to the symbol for which the string > "#id=" identifies. > <ref>:<typedef2>;<liverange>;<liverange>... > Defines an alias for the symbol identified by the reference > number ID. > l(<ref1>,<ref2>) > When used within a live range, "#id" refers to the text > symbol identified by "#id=" to use as the range symbol. > > <liverange> - "l(<ref_from>,<ref_to>)" - specifies a live range for a > symbol. Multiple "l" specifiers can be combined to represent > mutiple live ranges, separated by semicolons. > > > > The only thing I could think of was maybe some early developmental > code did not parse <liverange> as a single entity and thus needed > to handle the comma between <ref_from> and <ref_to> in the loop. > > HJ, can you try making the change I mentioned above and let me know > if it works? > Can someone please send me a patch? I am working on several other things at this momemnt. gdb is the last thing I want to fix right now. Thanks. -- H.J. Lu (hjl@gnu.org)