This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk 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: is UNW_REMOTE_ONLY in-dispensable fro Frysk


Alexandre Oliva wrote:
On Sep 11, 2006, Andrew Cagney <cagney@redhat.com> wrote:

Wu Zhou wrote:
UNW_REMOTE_ONLY is causing some trouble for us to work on ppc64
porting of libunwind. I am thinking over if it is in-dispensable
for Frysk.
I don't think it is in-dispensable, however, it is correct on
principle - this code has no need to do native unwinding - and it lets
us avoid a number of ongoing issues where the native-unwind defined
symbols that clashed with libgcj.

Alex, what I've said stands. If this isn't fixed, it isn't possible to do an unwind of a remote process.
Those internal routines need to be fixed. Can the upstream list's attention be drawn to this?


Actually, we absolutely must do away with it.  A number of libunwind
internal routines mmap or otherwise copy stuff from the target process
and then decode it locally, for which it needs functional
local_address_space callbacks.  One might try to qualify that as a
bug, but unless we're willing to fix that by rewriting a lot of code,
we'll be better off simply removing this local hack.  That's what the
patch I just posted (in the thread remote dwarf info using libunwind)
does, and this is the reason for the change, that I think I failed to
explain there.

Perhaps something to discuss on the libunwind list?

Probably not, given that it's a local change.
Since the long term objective is to carry no local patches for these libraries this stuff all needs to be discussed and pushed up-stream. Is there a technical reason for not doing this?

Andrew



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