New GDB 4.17 snapshot is available
Jeffrey A Law
law@cygnus.com
Tue Mar 17 23:36:00 GMT 1998
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?
Thanks,
jeff
More information about the Gdb-testers
mailing list