* Invalid registers @ 2005-07-11 15:42 Andrew STUBBS 2005-07-11 15:49 ` Daniel Jacobowitz 0 siblings, 1 reply; 15+ messages in thread From: Andrew STUBBS @ 2005-07-11 15:42 UTC (permalink / raw) To: GDB Hi, I have been having a little trouble updating from GDB 5.3 to GDB 6.3. It used to be the case that GDB would report '*value not available*' (for SH - I haven't checked other architectures) if the value of a register is not known in the current stack frame. However, it no longer does this. Since I assume it has not acquired some way to find out what that value was, I also assume this is somehow broken. (Note that SH already was broken in this respect for fp registers etc.) The code to print the data, in sh-tdep.c, has not changed greatly. It still calls frame_register_read() to discover the status of each register. However, deep in regcache.c, the code to handle this sort of thing has changed somewhat (indeed a few 'deprecated_...'s have got into the mix). The result is that no register is ever marked invalid. I cannot find out how (or where) it is supposed to know whether a register is invalid or not. Nor can I find any relevant discussion on the subject by googling (or I don't recognise it when I see it). Has this problem been fixed since 6.3 or become somehow obsolete? If not, any clues how to fix it? Thanks Andrew Stubbs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-11 15:42 Invalid registers Andrew STUBBS @ 2005-07-11 15:49 ` Daniel Jacobowitz 2005-07-11 18:47 ` Marcel Moolenaar 2005-07-12 16:07 ` Andrew STUBBS 0 siblings, 2 replies; 15+ messages in thread From: Daniel Jacobowitz @ 2005-07-11 15:49 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote: > Hi, > > I have been having a little trouble updating from GDB 5.3 to GDB 6.3. > > It used to be the case that GDB would report '*value not available*' (for > SH - I haven't checked other architectures) if the value of a register is > not known in the current stack frame. However, it no longer does this. > Since I assume it has not acquired some way to find out what that value > was, I also assume this is somehow broken. How's it supposed to know that the value is not available? If you want to do this based on the standard call ABI, please take a look at the current callers of dwarf2_frame_set_init_reg. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-11 15:49 ` Daniel Jacobowitz @ 2005-07-11 18:47 ` Marcel Moolenaar 2005-07-11 18:51 ` Daniel Jacobowitz 2005-07-12 16:16 ` Andrew STUBBS 2005-07-12 16:07 ` Andrew STUBBS 1 sibling, 2 replies; 15+ messages in thread From: Marcel Moolenaar @ 2005-07-11 18:47 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andrew STUBBS, GDB On Jul 11, 2005, at 8:49 AM, Daniel Jacobowitz wrote: > On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote: >> Hi, >> >> I have been having a little trouble updating from GDB 5.3 to GDB 6.3. >> >> It used to be the case that GDB would report '*value not available*' >> (for >> SH - I haven't checked other architectures) if the value of a >> register is >> not known in the current stack frame. However, it no longer does this. >> Since I assume it has not acquired some way to find out what that >> value >> was, I also assume this is somehow broken. > > How's it supposed to know that the value is not available? Given that registers are available when a value has been supplied, it's logical to assume (a priori) that a register is unavailable when no value has been supplied. A register's valid "bit" allows for this since there are 2 states that indicate unavailability: One that indicates a temporary state (0) and one that indicates a permanent state (-1). The initial state of a register is the temporarily unavailable state, which triggers fetching the register from the target. The target can change the state to permanently unavailable or supply the value (it can also, theoretically at least, leave the state unmodified and not provide a value). Hence, the a priori assumption that registers are unavailable when no value has been supplied (i.e. when the valid "bit" is not 1) seems to yield good behaviour when implemented as such. I would say then that gdb knows when a value is not available. Unfortunately, there are various bugs in this respect. A typical bug is to test for (register_valid_p[regnum]) to check if the register is cached, which ignores the <0 state for unavailable. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-11 18:47 ` Marcel Moolenaar @ 2005-07-11 18:51 ` Daniel Jacobowitz 2005-07-11 19:08 ` Marcel Moolenaar 2005-07-12 16:16 ` Andrew STUBBS 1 sibling, 1 reply; 15+ messages in thread From: Daniel Jacobowitz @ 2005-07-11 18:51 UTC (permalink / raw) To: Marcel Moolenaar; +Cc: Andrew STUBBS, GDB On Mon, Jul 11, 2005 at 11:47:01AM -0700, Marcel Moolenaar wrote: > Given that registers are available when a value has been supplied, > it's logical to assume (a priori) that a register is unavailable > when no value has been supplied. You are talking about a completely different meaning of unavailable than Andrew was. He's talking about unwinding, i.e. registers which have been modified but not saved by an intervening stack frame. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-11 18:51 ` Daniel Jacobowitz @ 2005-07-11 19:08 ` Marcel Moolenaar 0 siblings, 0 replies; 15+ messages in thread From: Marcel Moolenaar @ 2005-07-11 19:08 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andrew STUBBS, GDB On Jul 11, 2005, at 11:51 AM, Daniel Jacobowitz wrote: > On Mon, Jul 11, 2005 at 11:47:01AM -0700, Marcel Moolenaar wrote: >> Given that registers are available when a value has been supplied, >> it's logical to assume (a priori) that a register is unavailable >> when no value has been supplied. > > You are talking about a completely different meaning of unavailable > than Andrew was. He's talking about unwinding, i.e. registers which > have been modified but not saved by an intervening stack frame. Ah, I see. Wouldn't this apply only to caller-saved registers? And wouldn't it be reasonable to mark them as unavailable unless proven otherwise? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-11 18:47 ` Marcel Moolenaar 2005-07-11 18:51 ` Daniel Jacobowitz @ 2005-07-12 16:16 ` Andrew STUBBS 2005-07-12 17:19 ` Marcel Moolenaar 1 sibling, 1 reply; 15+ messages in thread From: Andrew STUBBS @ 2005-07-12 16:16 UTC (permalink / raw) To: Marcel Moolenaar, Daniel Jacobowitz; +Cc: GDB On Mon, 11 Jul 2005 19:47:01 +0100, Marcel Moolenaar <marcel@cup.hp.com> wrote: > Given that registers are available when a value has been supplied, > it's logical to assume (a priori) that a register is unavailable > when no value has been supplied. A register's valid "bit" allows > for this since there are 2 states that indicate unavailability: > One that indicates a temporary state (0) and one that indicates a > permanent state (-1). The initial state of a register is the temporarily > unavailable state, which triggers fetching the register from the > target. The target can change the state to permanently unavailable > or supply the value (it can also, theoretically at least, leave the > state unmodified and not provide a value). Hence, the a priori > assumption that registers are unavailable when no value has been > supplied (i.e. when the valid "bit" is not 1) seems to yield good > behaviour when implemented as such. I would say then that gdb knows > when a value is not available. Thanks, I did look at this before I posted, but I concluded that I was not what I was looking for. I mean, how would the target know what frame you were in? I do not know what it means for a register to be invalid in the target. Might it be because some registers are not available when, for example, the FPU is disabled? In any case, my target is always happy to supply registers. Andrew Stubbs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-12 16:16 ` Andrew STUBBS @ 2005-07-12 17:19 ` Marcel Moolenaar 0 siblings, 0 replies; 15+ messages in thread From: Marcel Moolenaar @ 2005-07-12 17:19 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB, Daniel Jacobowitz On Jul 12, 2005, at 9:13 AM, Andrew STUBBS wrote: > On Mon, 11 Jul 2005 19:47:01 +0100, Marcel Moolenaar > <marcel@cup.hp.com> wrote: >> Given that registers are available when a value has been supplied, >> it's logical to assume (a priori) that a register is unavailable >> when no value has been supplied. A register's valid "bit" allows >> for this since there are 2 states that indicate unavailability: >> One that indicates a temporary state (0) and one that indicates a >> permanent state (-1). The initial state of a register is the >> temporarily >> unavailable state, which triggers fetching the register from the >> target. The target can change the state to permanently unavailable >> or supply the value (it can also, theoretically at least, leave the >> state unmodified and not provide a value). Hence, the a priori >> assumption that registers are unavailable when no value has been >> supplied (i.e. when the valid "bit" is not 1) seems to yield good >> behaviour when implemented as such. I would say then that gdb knows >> when a value is not available. > > Thanks, I did look at this before I posted, but I concluded that I was > not what I was looking for. I mean, how would the target know what > frame you were in? You only ask the target about the current or interrupted state (i.e. frame #0). From that you unwind to the state of the frame in question. I noticed that even in frame #0 all registers were displayed. Even if I marked some of them as unavailable. This of course affects unwinding as well. So, even though I misunderstood the context, the issues are closely related. > I do not know what it means for a register to be invalid in the > target. Might it be because some registers are not available when, for > example, the FPU is disabled? Yes, that could be a possibility. On ia64, for example, the number of stacked registers is variable. gdb currently displays all 96 of them, even if the frame has only 3 stacked registers allocated. Other examples include registers that are simply not exposed through ptrace(2) or saved in core files. That is, the set of registers available to gdb may vary between operating systems. It makes sense for gdb to know about the superset, but it would be nice if it then didn't output 0 values for registers that aren't available as that may cause confusion. BTW: this isn't a big deal, because you can debug your code anyway. It's just (much) nicer to be able to represent reality better. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-11 15:49 ` Daniel Jacobowitz 2005-07-11 18:47 ` Marcel Moolenaar @ 2005-07-12 16:07 ` Andrew STUBBS 2005-07-12 17:34 ` Daniel Jacobowitz 1 sibling, 1 reply; 15+ messages in thread From: Andrew STUBBS @ 2005-07-12 16:07 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: GDB On Mon, 11 Jul 2005 16:49:26 +0100, Daniel Jacobowitz <drow@false.org> wrote: > On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote: >> Hi, >> >> I have been having a little trouble updating from GDB 5.3 to GDB 6.3. >> >> It used to be the case that GDB would report '*value not available*' >> (for >> SH - I haven't checked other architectures) if the value of a register >> is >> not known in the current stack frame. However, it no longer does this. >> Since I assume it has not acquired some way to find out what that value >> was, I also assume this is somehow broken. > > How's it supposed to know that the value is not available? If you want > to do this based on the standard call ABI, please take a look at the > current callers of dwarf2_frame_set_init_reg. Thank you. This has helped me find the right stuff to look at. I do not think I actually want to use dwarf2_frame_set_init_reg. The compiler (GCC 3.4.3) produces CFI information which I think ought to be enough. The function execute_cfa_program in dwarf2-frame.c appears to load all the relevant data (setting breakpoints in strategic places show this). If I use 'up' and 'info registers' I see the values change, which shows that the CFI data has been loaded (doesn't it?). It just appears that the 'how' field from the CFA is being ignored when the values are printed. Setting 'how' via dwarf2_frame_set_init_reg is not ignored however. It must be being reset, or perhaps not copied in the first place. Any clues? Thanks Andrew Stubbs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-12 16:07 ` Andrew STUBBS @ 2005-07-12 17:34 ` Daniel Jacobowitz 2005-07-13 15:13 ` Andrew STUBBS 0 siblings, 1 reply; 15+ messages in thread From: Daniel Jacobowitz @ 2005-07-12 17:34 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB On Tue, Jul 12, 2005 at 05:04:41PM +0100, Andrew STUBBS wrote: > Thank you. This has helped me find the right stuff to look at. > > I do not think I actually want to use dwarf2_frame_set_init_reg. The > compiler (GCC 3.4.3) produces CFI information which I think ought to be > enough. > > The function execute_cfa_program in dwarf2-frame.c appears to load all the > relevant data (setting breakpoints in strategic places show this). If I > use 'up' and 'info registers' I see the values change, which shows that > the CFI data has been loaded (doesn't it?). It just appears that the 'how' > field from the CFA is being ignored when the values are printed. Setting > 'how' via dwarf2_frame_set_init_reg is not ignored however. It must be > being reset, or perhaps not copied in the first place. > > Any clues? Sorry, not enough information - I'd need specifics. GCC's CFI generally does not represent call-clobbered registers; waste of space for a runtime unwinder. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-12 17:34 ` Daniel Jacobowitz @ 2005-07-13 15:13 ` Andrew STUBBS 2005-07-13 15:42 ` Daniel Jacobowitz 0 siblings, 1 reply; 15+ messages in thread From: Andrew STUBBS @ 2005-07-13 15:13 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: GDB On Tue, 12 Jul 2005 18:34:50 +0100, Daniel Jacobowitz <drow@false.org> wrote: > Sorry, not enough information - I'd need specifics. GCC's CFI > generally does not represent call-clobbered registers; waste of space > for a runtime unwinder. Ok, after further investigation, here's what I'm seeing. The default init_reg function, dwarf2_frame_default_init_reg, sets up the PC and stack pointer registers so that they do the right thing. Additionally, the CFI information describes how the R14 (frame pointer) and PR (saved PC) registers are saved to the stack. With this setup, 'frame 1' followed by 'info all-registers' shows the correct values (I assume) for the four registers above, and (potentially) incorrect values for everything else. So I set up a function, as follows, to tell it that anything is invalid, unless it knows otherwise: sh_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum, struct dwarf2_frame_state_reg *reg) { /* Mark PC as destination for the return address. */ if (regnum == PC_REGNUM) reg->how = DWARF2_FRAME_REG_RA; /* Mark stack pointer set it to the call frame address. */ else if (regnum == SP_REGNUM) reg->how = DWARF2_FRAME_REG_CFA; /* Mark all other registers as invalid. Braindead, but ok for now. */ else reg->how = DWARF2_FRAME_REG_UNDEFINED; } With this function I get different wrong behaviour. Now I get all but PC and R15 (stack pointer) as '*value not available*'. I had expected that that the CFI would override the initialised values because it knows best (just because it is called 'init', not 'set), but neither R14 nor PR have their true values listed despite execute_cfa_program extracting a 'how' value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case, but should it be? Obviously the function above is overkill, in any case, because callee saved registers always have a useful value in them - either they have not changed or they have been saved and the CFI knows about it. I could fix that by just looking up exactly which they are and encoding it into the function above. However, it is not clear to me what to do with caller save registers. If I just set them to undefined, as above, then they will never have a value, but are there sometimes saved values for those registers (saved by the caller) and cannot CFI describe this? In short, is it always the case that call clobblered registers are unavailable? I know the PR register is technically caller save, but has a CFI entry in my test program, but then in practice PR is really treated as callee save anyway. Is that just a special case? Thanks Andrew Stubbs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-13 15:13 ` Andrew STUBBS @ 2005-07-13 15:42 ` Daniel Jacobowitz 2005-07-13 16:16 ` Andrew STUBBS 2005-07-14 9:36 ` Andrew STUBBS 0 siblings, 2 replies; 15+ messages in thread From: Daniel Jacobowitz @ 2005-07-13 15:42 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote: > With this function I get different wrong behaviour. Now I get all but PC > and R15 (stack pointer) as '*value not available*'. I had expected that > that the CFI would override the initialised values because it knows best > (just because it is called 'init', not 'set), but neither R14 nor PR have > their true values listed despite execute_cfa_program extracting a 'how' > value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case, but > should it be? Why isn't it? Please debug this, since reading the code clearly suggests it works as you expect. See dwarf2_frame_cache. > Obviously the function above is overkill, in any case, because callee > saved registers always have a useful value in them - either they have not > changed or they have been saved and the CFI knows about it. I could fix > that by just looking up exactly which they are and encoding it into the > function above. Correct. > However, it is not clear to me what to do with caller save registers. If I > just set them to undefined, as above, then they will never have a value, > but are there sometimes saved values for those registers (saved by the > caller) and cannot CFI describe this? In short, is it always the case that No, it can't. CFI describes the state at the call instruction, from the point of view of the called function. It's not conceptually impossible to describe caller saved registers, but no compiler I'm familiar with does it... > call clobblered registers are unavailable? I know the PR register is Only if they are clobbered. That's why GDB defaults to showing them anyway; it is often useful, although sometimes wrong. > technically caller save, but has a CFI entry in my test program, but then > in practice PR is really treated as callee save anyway. Is that just a > special case? I would need to see the CFI, sorry - I can't follow exactly what you mean. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-13 15:42 ` Daniel Jacobowitz @ 2005-07-13 16:16 ` Andrew STUBBS 2005-07-13 20:27 ` Daniel Jacobowitz 2005-07-14 9:36 ` Andrew STUBBS 1 sibling, 1 reply; 15+ messages in thread From: Andrew STUBBS @ 2005-07-13 16:16 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: GDB On Wed, 13 Jul 2005 16:42:07 +0100, Daniel Jacobowitz <drow@false.org> wrote: > On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote: >> With this function I get different wrong behaviour. Now I get all but PC >> and R15 (stack pointer) as '*value not available*'. I had expected that >> that the CFI would override the initialised values because it knows best >> (just because it is called 'init', not 'set), but neither R14 nor PR >> have >> their true values listed despite execute_cfa_program extracting a 'how' >> value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case, >> but >> should it be? > > Why isn't it? Please debug this, since reading the code clearly > suggests it works as you expect. See dwarf2_frame_cache. I'll see what I can find. >> I know the PR register is >> technically caller save, but has a CFI entry in my test program, but >> then >> in practice PR is really treated as callee save anyway. Is that just a >> special case? > > I would need to see the CFI, sorry - I can't follow exactly what you > mean. The SH ABI lists the PR register (in which the PC is saved by a branch to subroutine) as caller save. This is true because a function has to save it before calling a subroutine. However, in practice it can be viewed as a callee save register because all non-leaf functions save it in the function prologue. GCC appears to be emitting CFI information for PR as if it was callee save. You say that there should be no CFI for caller saved registers, so I'll take that as answering my question. Thanks Andrew Stubbs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-13 16:16 ` Andrew STUBBS @ 2005-07-13 20:27 ` Daniel Jacobowitz 0 siblings, 0 replies; 15+ messages in thread From: Daniel Jacobowitz @ 2005-07-13 20:27 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB On Wed, Jul 13, 2005 at 05:14:02PM +0100, Andrew STUBBS wrote: > The SH ABI lists the PR register (in which the PC is saved by a branch to > subroutine) as caller save. This is true because a function has to save it > before calling a subroutine. However, in practice it can be viewed as a > callee save register because all non-leaf functions save it in the > function prologue. GCC appears to be emitting CFI information for PR as if > it was callee save. > > You say that there should be no CFI for caller saved registers, so I'll > take that as answering my question. Sorry, at some point you got me turned around with my own terminology. Let me try again, more coherently. CFI describes saved registers. It can describe any saved register; typically, however, it only describes enough state to unwind to the state as-of any call instruction, i.e. to describe any frame on the stack. At a call instruction there is still code in the caller to be executed which will reload the caller saved registers; that code can be freely scheduled, it is not part of the call sequence. So typically it is not described. Those registers are dead at the call site and given interesting values again later. While the registers may be conceptually unavailable, the variables in them are not - if your compiler emits good location lists, they'll reflect the stack slots used. So the value for PR we want to recover while unwinding is the value it had "at the call site" - generally unavailable. But we can figure out what it was just after the call site, where the prologue will often have saved it, and use that to determine where to unwind to. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-13 15:42 ` Daniel Jacobowitz 2005-07-13 16:16 ` Andrew STUBBS @ 2005-07-14 9:36 ` Andrew STUBBS 2005-07-14 14:11 ` Daniel Jacobowitz 1 sibling, 1 reply; 15+ messages in thread From: Andrew STUBBS @ 2005-07-14 9:36 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: GDB On Wed, 13 Jul 2005 16:42:07 +0100, Daniel Jacobowitz <drow@false.org> wrote: > On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote: >> With this function I get different wrong behaviour. Now I get all but PC >> and R15 (stack pointer) as '*value not available*'. I had expected that >> that the CFI would override the initialised values because it knows best >> (just because it is called 'init', not 'set), but neither R14 nor PR >> have >> their true values listed despite execute_cfa_program extracting a 'how' >> value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case, >> but >> should it be? > > Why isn't it? Please debug this, since reading the code clearly > suggests it works as you expect. See dwarf2_frame_cache. I think I have found the 'problem'. It is working as it should, but it doesn't look like it at first sight. When I set a breakpoint on a function it breaks _before_ the callee save registers have been saved (this may be a mistake, I'm not sure yet). If I step into the function a little more then the CFI kicks in and it overrides the initial settings I put in. What confused my is that there is more than one frame available at once (of course), and when debugging it is not always clear which one I am looking at, especially when it is typically the same set of registers being saved. Thank you for all your help. Apologies for being thick. Now onto the next issue .... Andrew Stubbs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Invalid registers 2005-07-14 9:36 ` Andrew STUBBS @ 2005-07-14 14:11 ` Daniel Jacobowitz 0 siblings, 0 replies; 15+ messages in thread From: Daniel Jacobowitz @ 2005-07-14 14:11 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB On Thu, Jul 14, 2005 at 10:33:25AM +0100, Andrew STUBBS wrote: > It is working as it should, but it doesn't look like it at first sight. > When I set a breakpoint on a function it breaks _before_ the callee save > registers have been saved (this may be a mistake, I'm not sure yet). If I Yes - this is generally a mistake, either in the prologue analyzer or in your compiler's generated line info. But it isn't necessarily an important mistake. > step into the function a little more then the CFI kicks in and it > overrides the initial settings I put in. Right. This is a little unfortunate, but I don't know what we can do about it - it seems unlikely to be worth the trouble. FWIW, a compiler _could_ generate sufficiently detailed CFI for this. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-07-14 14:11 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-11 15:42 Invalid registers Andrew STUBBS 2005-07-11 15:49 ` Daniel Jacobowitz 2005-07-11 18:47 ` Marcel Moolenaar 2005-07-11 18:51 ` Daniel Jacobowitz 2005-07-11 19:08 ` Marcel Moolenaar 2005-07-12 16:16 ` Andrew STUBBS 2005-07-12 17:19 ` Marcel Moolenaar 2005-07-12 16:07 ` Andrew STUBBS 2005-07-12 17:34 ` Daniel Jacobowitz 2005-07-13 15:13 ` Andrew STUBBS 2005-07-13 15:42 ` Daniel Jacobowitz 2005-07-13 16:16 ` Andrew STUBBS 2005-07-13 20:27 ` Daniel Jacobowitz 2005-07-14 9:36 ` Andrew STUBBS 2005-07-14 14:11 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).