This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [patch] Speed up find_pc_section


The patch looks OK (not that I have any say on this),
but I am still puzzled by what can happen if
you have overlapping sections in the end.

  Is the CORE_ADDR to section mapping still 
deterministic in that case?
  Using binary search for ill order item
can lead to different results if you add
items to the list, no?
  And I suspect that dynamic loading of 
library can add items to the list with running 
a debuggee, thus leading to a different result 
before and after that loading for the same CORE_ADDR.
  
  Shouldn't we by brute force shorten one of the two
overlapping sections to remove that error?
  If I understood your patch correctly,
it doesn't do that for now.
  Please tell me if I am wrong.

Adding a simple
	 obj_section_endaddr (sect1):= sect2_addr;
after the complaint should be enough to
be sure that the binary search is deterministic, no?



Pierre Muller
Pascal language support maintainer for GDB




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]