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]

Re: New GDB 4.17 snapshot is available


  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