Re: [libunwind] remote unwinding and dynamically-generated code

[Todd L Miller]

>    Also, I'm not terribly fond of the "flags" name.  How about calling
>    it "busy", or at least "busy_flag").  I don't think it's a good idea
>    to pretend we're supporting mutiple flags.  If we did that, we would
>    have to use atomic update instructions; I do not think that's worth
>    the trouble.

        I wasn't certain how much 'future-proofing' you wanted, and it
seemed kind of silly to dedicate a full 32 bits to a single flag.
However, your point about atomic updates is well taken, and I've changed
the header to suit (as well as the ordering problem you pointed out
earlier).

>  - The typedef for the UNW_DYN_INFO_LIST_VERSIONs seems overkill to me.

        Well, it probably is. :)

[snip]

>    Code implementing backwards-compatibility uses open-coded
>    constants, because it does not want to be subject to changes in the
>    macros.

        I must admit that I haven't the faintest idea what you mean here.
(What's "open-coded" mean?  Why would a typedef be subject to changes in
macros?  Or did you mean that if the code were to support old-style
dynamic info lists, it would do so by checking explicitly for '0' (and
'1'), rather than DYN_INFO_LIST_VERSION?)

        I'm working on your other points.

- Todd