[llvm] r174543 - Add a test for checking the current .debug_frame dumping capability.

Fri Feb 8 19:48:38 PST 2013

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?

Eli

On Thu, Feb 7, 2013 at 3:28 PM, David Tweed <David.Tweed at arm.com> wrote:

> Hi Eli,
>
> 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,
>
> Cheers,
> Dave
> ________________________________________
> From: David Tweed
> Sent: Thursday, February 07, 2013 3:52 PM
> To: David Tweed; 'Renato Golin'; Eli Bendersky
> Cc: LLVM Commits
> Subject: RE: [llvm] r174543 - Add a test for checking the current
> .debug_frame    dumping capability.
>
> 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.
>
> I'll whip up a patch to change the format string and commit.
>
> Cheers,
> Dave
>
> From: David Tweed
> Sent: 07 February 2013 15:33
> To: David Tweed; 'Renato Golin'; Eli Bendersky
> Cc: LLVM Commits
> Subject: RE: [llvm] r174543 - Add a test for checking the current
> .debug_frame dumping capability.
>
> 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.
>
> 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?
>
> Cheers,
> Dave
>
> From: llvm-commits-bounces at cs.uiuc.edu<mailto:
> llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-bounces at cs.uiuc.edu]
> On Behalf Of David Tweed
> Sent: 07 February 2013 12:52
> To: 'Renato Golin'; Eli Bendersky
> Cc: LLVM Commits
> Subject: RE: [llvm] r174543 - Add a test for checking the current
> .debug_frame dumping capability.
>
> Further to Renato's comments:
>
> 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
>
> 00000014 00000010 beaebe7f FDE cie=00000000 pc=00000000...beaebe7f
>
> 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.)
>
> Cheers,
> Dave
>
> From: llvm-commits-bounces at cs.uiuc.edu<mailto:
> llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-bounces at cs.uiuc.edu]
> On Behalf Of Renato Golin
> Sent: 07 February 2013 10:39
> To: Eli Bendersky
> Cc: LLVM Commits
> Subject: Re: [llvm] r174543 - Add a test for checking the current
> .debug_frame dumping capability.
>
> Hi Eli,
>
> This test is not working on ARM buildbots...
>
>
> 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
>
>
> 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
>
> thanks,
> --renato
>
> On 6 February 2013 20:55, Eli Bendersky <eliben at google.com<mailto:
> eliben at google.com>> wrote:
> Author: eliben
> Date: Wed Feb  6 14:55:06 2013
> New Revision: 174543
>
> URL: http://llvm.org/viewvc/llvm-project?rev=174543&view=rev
> Log:
> Add a test for checking the current .debug_frame dumping capability.
>
> The test is a binary placed in test/DebugInfo/Inputs, with a source C
> file used for reference/reproducing. The source's first line is a clang
> build command for reproducing the binary.
>
>
> Added:
>     llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c
>     llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o   (with
> props)
>     llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test
>
> Added: llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c?rev=174543&view=auto
>
> ==============================================================================
> --- llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c (added)
> +++ llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.c Wed Feb  6
> 14:55:06 2013
> @@ -0,0 +1,14 @@
> +// clang -c -g -o dwarfdump-test-32bit.elf.o -m32
> dwarfdump-test-32bit.elf.c
> +
> +extern int glob;
> +
> +int foo(int arg) {
> +  int a = arg * 2;
> +  return a + glob;
> +}
> +
> +int bar(int arg) {
> +  int a = foo(arg) * foo(arg * 2);
> +  return glob - foo(a);
> +}
> +
>
> Added: llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o?rev=174543&view=auto
>
> ==============================================================================
> Binary file - no diff available.
>
> Propchange: llvm/trunk/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o
>
> ------------------------------------------------------------------------------
>     svn:mime-type = application/octet-stream
>
> Added: llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test?rev=174543&view=auto
>
> ==============================================================================
> --- llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test (added)
> +++ llvm/trunk/test/DebugInfo/dwarfdump-debug-frame-simple.test Wed Feb  6
> 14:55:06 2013
> @@ -0,0 +1,14 @@
> +; RUN: llvm-dwarfdump %p/Inputs/dwarfdump-test-32bit.elf.o
> -debug-dump=frames | FileCheck %s -check-prefix FRAMES
> +
> +; FRAMES: .debug_frame
> +; FRAMES-NOT: .eh_frame
> +
> +; FRAMES: 00000000 00000010 ffffffff CIE
> +; FRAMES: Version: 1
> +
> +; FRAMES: 00000014 00000010 00000000 FDE cie=00000000
> pc=00000000...00000022
> +; FRAMES: 00000028 00000014 00000000 FDE cie=00000000
> pc=00000030...00000080
> +
> +; FRAMES-NOT: CIE
> +; FRAMES-NOT: FDE
> +
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
> -- 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.
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130208/a8c7c1f4/attachment.html>