This is the mail archive of the gdb-patches@sources.redhat.com 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] |
- Can infcall.c instead explicitly call CONVERT_FROM_FUNC_PTR_ADDR onCALL_DUMMY_ADDRESS, or better, have entry_point_address do this? It would help eliminate CALL_DUMMY_ADDRESS.
I'm not sure I understand enough of the details to say anything about this. Why isn't infcall.c just using entry_point_address right now?
So, given a function descriptor at VMA bfd_get_start_address(), thereare two possible code addresses:
- The relocated address found by reading the descriptor from the target. This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), target memory)?
- The un-relocated address found by reading the descriptor from the bfd. This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), use bfd memory)?
and the two values are different. Hence the new method.
That's the important difference, yes. The trick the solib code uses to find the dynamic linker's load offset really does need the unrelocated address --- the amount by which it would need to be relocated is exactly what we're computing there.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |