search for: pr13303

Hi David, I think it might not be exactly PR13303 which might be causing the corruption of struct when accessed through GDB. This seems to be an ABI problem in clang. The problem seems to be that when we have pass by value of struct (having indirect arguments) stack is not aligned properly. I tried realigning the stack for indirect arguments in(T...

On Thu, Dec 6, 2012 at 12:33 AM, Karthik Bhat <karthikthecool at gmail.com> wrote: > Hi David, > > I think it might not be exactly PR13303 which might be causing the > corruption of struct when accessed through GDB. > This seems to be an ABI problem in clang. > The problem seems to be that when we have pass by value of struct > (having indirect arguments) stack is not aligned properly. > > I tried realigning the stac...

This seems to be another case of PR13303 - since GDB can't figure out where to break for this function based on the debug info (you'll notice when you "break recurse" that it's not breaking on a line or source file, just an address) it's breaking at the very start, before the prologue I'm about to commit a f...

Hi All, I was debugging a clang binary when i found this problem. The following code is complied with clang. typedef struct s { short s; } SVAL; void recurse (SVAL a, int depth) { a.s = --depth; if (depth == 0) return; else recurse(a,depth); } int main () { SVAL s; s.s = 5; recurse (s, 5); return 0; } When i try to access value of a.s in function recurse through gdb(i.e

...yeah, they could be separate, but I'd >> expect the assembler and object file emission to be tested separately >> already - the only benefit to testing particular IR->object & >> separately testing particular IR->assembly is probably not worthwhile. > > I cite PR13303/PR14524, where asm and direct-object output differ. > This came up early in my LLVM career and has doubtless poisoned my > outlook for life.... > > In many cases I think the same test _source_ can be used to check both > asm and object, with appropriate RUN lines, and whether you wan...

...enerally go in LLVM - yeah, they could be separate, but I'd > expect the assembler and object file emission to be tested separately > already - the only benefit to testing particular IR->object & > separately testing particular IR->assembly is probably not worthwhile. I cite PR13303/PR14524, where asm and direct-object output differ. This came up early in my LLVM career and has doubtless poisoned my outlook for life.... In many cases I think the same test _source_ can be used to check both asm and object, with appropriate RUN lines, and whether you want to count that as the s...

Hello, A recent series of commits, ending with r169304 and relating to PR13303, add is_stmt to line entries for functions. This appears to be to work around problems with gdb. However, I observe is_stmt is not always applied to line entries for functions. This may only affect the arm backend. Compiling the same code with the aarch64 backend does not demonstrate this problem....

On Tue, Jan 22, 2013 at 3:23 PM, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: >>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>>> cumbersome and misses a lot of things like actual DWARF encoding. >>> >>> I'm not sure what you mean by "actual DWARF encoding" here. >>> (disclaimer: I've only