Re: is UNW_REMOTE_ONLY in-dispensable fro Frysk

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep 14, 2006, Andrew Cagney <cagney@redhat.com> wrote:

> 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?

No, I think I wasn't clear in my explanation, which led you to
incorrect conclusions.

I was not talking about the routines we tried to use before and failed
because they were *not* meant to be used for remote unwinding.

I'm talking about other routines used internally that extract
unwind information from files or from copying data from the remote
process to the local process, and then extract the info accessing the
then-local memory.

>> 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?

No, quite the contrary.  Reverting this local change fixes bugs and I
don't see a reason for this change other than a misguided attempt to
reduce code size of compilation time or some such.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}