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]

jit_breakpoint_re_set_internal desc_symbol issue


Hi.

I'm now seeing this failure.

Unknown action_flag value in JIT descriptor!
(gdb) FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: Can't run to main

The problem is that the msymbol computed here:

jit.c:jit_breakpoint_re_set_internal:

      desc_symbol = lookup_minimal_symbol (jit_descriptor_name, NULL,
					   reg_symbol.objfile);

is clobbered when we resort minsyms due to objfile relocation here:

objfiles.c:objfile_relocate1:

  /* Relocating different sections by different amounts may cause the symbols
     to be out of order.  */
  msymbols_sort (objfile);

which is ultimately called as part of infcmd.c:post_create_inferior.

I haven't dug into why this only just started happening,
seems like the bug has been there for awhile.

Given the call to msymbols_sort in objfile_relocate1 I think any
caching of minsym lookups needs to be careful to flush the cache
when such things happen.
However, I don't see a current mechanism to do this.
Do we need observer_notify_objfile_changed?
[And if we had it could we use it to clean up a few calls to breakpoint_re_set?
Dunno.]

A hacky solution would be to use observer_notify_inferior_created.
[i.e. use it to recompute jit.c:desc_symbol]
It will get called at the end of infcmd.c:post_create_inferior.

I'm not sure what the right fix is here.
Suggestions?

[
Another thing that bothers me is breakpoint_re_set.
We call it at the end of objfiles.c:objfile_relocate:

  /* Relocate breakpoints as necessary, after things are relocated.  */
  if (changed)
    breakpoint_re_set ();

And we will call it again at the end of infcmd.c:post_create_inferior:

  /* If the user sets watchpoints before execution having started,
     then she gets software watchpoints, because GDB can't know which
     target will end up being pushed, or if it supports hardware
     watchpoints or not.  breakpoint_re_set takes care of promoting
     watchpoints to hardware watchpoints if possible, however, if this
     new inferior doesn't load shared libraries or we don't pull in
     symbols from any other source on this target/arch,
     breakpoint_re_set is never called.  Call it now so that software
     watchpoints get a chance to be promoted to hardware watchpoints
     if the now pushed target supports hardware watchpoints.  */
  breakpoint_re_set ();

Ultimately breakpoint_re_set gets called four times inside the call
to post_create_inferior.  There's some cleanup to be had here.

To fix the jit.exp failure I might suggest just not caching jit.c:desc_symbol,
except that if we're going to lookup the same symbol four times inside
post_create_inferior that gives me pause.
]


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