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] |
On Sep 11, 2006, Andrew Cagney <cagney@redhat.com> wrote:Alex, what I've said stands. If this isn't fixed, it isn't possible to do an unwind of a remote process.
Wu Zhou wrote:
UNW_REMOTE_ONLY is causing some trouble for us to work on ppc64I don't think it is in-dispensable, however, it is correct on
porting of libunwind. I am thinking over if it is in-dispensable
for Frysk.
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.
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?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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |