<div dir="ltr">I believe this was fixed by Takumi, by casting the values to uint32_t before passing them to format. Do you still observe the problem after his fix?<br><br>Eli<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Feb 7, 2013 at 3:28 PM, David Tweed <span dir="ltr"><<a href="mailto:David.Tweed@arm.com" target="_blank">David.Tweed@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Eli,<br>
<br>
while it's easy to "fix" the format string the question arises whether they should be 64-bit values while the other elements are cast to uint32_t's. I don't know much about DWARF, and a brief scan through the downloadable spec doesn't obviously answer the question, are these the correct ranges of the values. I can imagine that, because of the way they're specified in the file, the indivdual values are 32-bits but they're sum can legitimately be larger than 32-bits. I'd welcome any information regarding this piont,<br>
<br>
Cheers,<br>
Dave<br>
________________________________________<br>
From: David Tweed<br>
Sent: Thursday, February 07, 2013 3:52 PM<br>
<div class="im">To: David Tweed; 'Renato Golin'; Eli Bendersky<br>
Cc: LLVM Commits<br>
</div>Subject: RE: [llvm] r174543 - Add a test for checking the current .debug_frame dumping capability.<br>
<div class="im"><br>
Aha: the issue wasn't a deep problem with variadic functions (which is a relief because I don't understand those enough to fix), it's the format string using %8x with a variable of type uint64_t. I guess on x86_64 (which is the default testing platform for most people these days I guess) you get lucky and the variadic calling convention just happens to give the right result, but on a 32-bit platform like ARM-v7 you end up reading from a location containing something else entirely.<br>
<br>
</div><div class="im">I'll whip up a patch to change the format string and commit.<br>
<br>
Cheers,<br>
Dave<br>
<br>
From: David Tweed<br>
Sent: 07 February 2013 15:33<br>
To: David Tweed; 'Renato Golin'; Eli Bendersky<br>
Cc: LLVM Commits<br>
Subject: RE: [llvm] r174543 - Add a test for checking the current .debug_frame dumping capability.<br>
<br>
Actually, I've been poking a bit more at this and ASSUMING I THE GDB OUTPUT IS RIGHT the actual values in the objects are the correct ones, something is going wrong in the process of printing them in llvm::format_object3<blah>. The values appear to be stored correctly in the llvm::format_object3 object but in being processed by printf something is going wrong with the third argument only. (I say "if I can trust gdb" because the layout when calling a variadic is context dependent, so if it's confused about the context it could be printing a different code-level interpretation of the registers.) It looks like it might be printing the stack-address of the third argument rather than its value, but I'm not sure about this.<br>
<br>
I'll perhaps keep looking, but I'm not really up on the magic of implementing variadic functions on any architecture, so if anyone is more experienced feel free to jump in and look at this. I also wonder why, if there's a snprintf issue occurring it doesn't affect more of the regression tests?<br>
<br>
Cheers,<br>
Dave<br>
<br>
</div>From: <a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a><mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a>> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a>] On Behalf Of David Tweed<br>
<div class="im">Sent: 07 February 2013 12:52<br>
To: 'Renato Golin'; Eli Bendersky<br>
Cc: LLVM Commits<br>
Subject: RE: [llvm] r174543 - Add a test for checking the current .debug_frame dumping capability.<br>
<br>
Further to Renato's comments:<br>
<br>
While I don't know either about ELF or how llvm-dwarfdump reads it, I observe that if I run the failing test multiple times the hex numbers<br>
<br>
00000014 00000010 beaebe7f FDE cie=00000000 pc=00000000...beaebe7f<br>
<br>
in the beaebe7f positions change between runs seemingly randomly (although they all start "be") (and a few other elements of such as the Data alignment factor and Return address column contain garbage), suggesting that it _may_ be something is being allocated on when run on ARM but not being filled in. But that diagnosis isn't certain obviously. (Unfortunately I can't currently run valgind on my pandaboard to check this directly.)<br>
<br>
Cheers,<br>
Dave<br>
<br>
</div>From: <a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a><mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a>> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a>] On Behalf Of Renato Golin<br>
<div class="im">Sent: 07 February 2013 10:39<br>
To: Eli Bendersky<br>
Cc: LLVM Commits<br>
</div>Subject: Re: [llvm] r174543 - Add a test for checking the current .debug_frame dumping capability.<br>
<div class="im"><br>
Hi Eli,<br>
<br>
This test is not working on ARM buildbots...<br>
<br>
<a href="http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a15/builds/16/steps/check-all/logs/LLVM%20%3A%3A%20DebugInfo__dwarfdump-debug-frame-simple.test" target="_blank">http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a15/builds/16/steps/check-all/logs/LLVM%20%3A%3A%20DebugInfo__dwarfdump-debug-frame-simple.test</a><br>
<br>
<a href="http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4861/steps/check-all/logs/LLVM%20%3A%3A%20DebugInfo__dwarfdump-debug-frame-simple.test" target="_blank">http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4861/steps/check-all/logs/LLVM%20%3A%3A%20DebugInfo__dwarfdump-debug-frame-simple.test</a><br>
<br>
thanks,<br>
--renato<br>
<br>
</div><div><div class="h5">On 6 February 2013 20:55, Eli Bendersky <<a href="mailto:eliben@google.com">eliben@google.com</a><mailto:<a href="mailto:eliben@google.com">eliben@google.com</a>>> wrote:<br>
Author: eliben<br>
Date: Wed Feb 6 14:55:06 2013<br>
New Revision: 174543<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=174543&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=174543&view=rev</a><br>
Log:<br>
Add a test for checking the current .debug_frame dumping capability.<br>
<br>
The test is a binary placed in test/DebugInfo/Inputs, with a source C<br>
file used for reference/reproducing. The source's first line is a clang<br>
build command for reproducing the binary.<br>
<br>
<br>
Added:<br>
llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c<br>
llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o (with props)<br>
llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test<br>
<br>
Added: llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c?rev=174543&view=auto" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c?rev=174543&view=auto</a><br>
==============================================================================<br>
--- llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c (added)<br>
+++ llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c Wed Feb 6 14:55:06 2013<br>
@@ -0,0 +1,14 @@<br>
+// clang -c -g -o dwarfdump-test-32bit.elf.o -m32 dwarfdump-test-32bit.elf.c<br>
+<br>
+extern int glob;<br>
+<br>
+int foo(int arg) {<br>
+ int a = arg * 2;<br>
+ return a + glob;<br>
+}<br>
+<br>
+int bar(int arg) {<br>
+ int a = foo(arg) * foo(arg * 2);<br>
+ return glob - foo(a);<br>
+}<br>
+<br>
<br>
Added: llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o?rev=174543&view=auto" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o?rev=174543&view=auto</a><br>
==============================================================================<br>
Binary file - no diff available.<br>
<br>
Propchange: llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o<br>
------------------------------------------------------------------------------<br>
svn:mime-type = application/octet-stream<br>
<br>
Added: llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test?rev=174543&view=auto" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test?rev=174543&view=auto</a><br>
==============================================================================<br>
--- llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test (added)<br>
+++ llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test Wed Feb 6 14:55:06 2013<br>
@@ -0,0 +1,14 @@<br>
+; RUN: llvm-dwarfdump %p/Inputs/dwarfdump-test-32bit.elf.o -debug-dump=frames | FileCheck %s -check-prefix FRAMES<br>
+<br>
+; FRAMES: .debug_frame<br>
+; FRAMES-NOT: .eh_frame<br>
+<br>
+; FRAMES: 00000000 00000010 ffffffff CIE<br>
+; FRAMES: Version: 1<br>
+<br>
+; FRAMES: 00000014 00000010 00000000 FDE cie=00000000 pc=00000000...00000022<br>
+; FRAMES: 00000028 00000014 00000000 FDE cie=00000000 pc=00000030...00000080<br>
+<br>
+; FRAMES-NOT: CIE<br>
+; FRAMES-NOT: FDE<br>
+<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
</div></div><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><mailto:<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br>
<div class="im HOEnZb"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
<br>
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>