pahole vs isatty

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I am using pahole 1.21 and I recently noticed that I no longer have
any pahole output in several scripts.


Using (on the command line):

$ pahole -V -E -C my_struct /path/to/my/debug.o

works fine and gives the expected output.


But

$ parallel -j 1 pahole -V -E -C my_struct ::: /path/to/my/debug.o

gives nothing, no stderr, no stdout and ret code 0.

After testing some versions, it works fine in 1.17 and no longer works in 1.18.

-> Git Bisect
$ git bisect start
$ git bisect good v1.17
$ git bisect bad v1.18
Bisecting: 54 revisions left to test after this (roughly 6 steps)
[0a97d6c143fcc92a335e532a991e1e1c62c9bd3e] pahole: Factor out parsing
class prototypes
$ git bisect bad
Bisecting: 26 revisions left to test after this (roughly 5 steps)
[a5bb31b86fbe53624165ecdf1bd18a19ac224b7c] pahole: Fix --skip for
variable sized records
$ git bisect bad
Bisecting: 13 revisions left to test after this (roughly 4 steps)
[fe284221448c950d2ba17bce91d19c484d6580a0] pahole: Introduce --seek_bytes
$ git bisect bad
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[a231d00f8d08825ea1c9937cf5c932883ad28ecc] pahole: Print comma at the
end of field name + field value
$ git bisect bad
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[cc65946e3068f7b68a0aa437261c748c20445986] dwarves: Adopt
tag__is_base_type() from ctrace.c
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[d8079c6d373a5754164ecd784844ce2622d782b8] pahole: Hex dump a type
from stdio when it isn't a tty
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[38109ab45fe0307dd21b96a866c1f9b62df64fd4] spec: Fix date
$ git bisect good
d8079c6d373a5754164ecd784844ce2622d782b8 is the first bad commit
commit d8079c6d373a5754164ecd784844ce2622d782b8
Author: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
Date:   Wed Jun 24 09:08:17 2020 -0300

    pahole: Hex dump a type from stdio when it isn't a tty

    For now the only aspect of the type that is considered is its size, so
    one line each sizeof(type) will be hex dumped, e.g.:

      $ objcopy -O binary --only-section=.altinstructions
~/git/build/v5.7-rc2+/vmlinux .altinstructions
      $ ls -la .altinstructions
      -rwxrwxr-x. 1 acme acme 18551 Jun 24 09:09 .altinstructions
      $ pahole -C alt_instr ~/git/build/v5.7-rc2+/vmlinux
      struct alt_instr {
            s32                        instr_offset;         /*     0     4 */
            s32                        repl_offset;          /*     4     4 */
            u16                        cpuid;                /*     8     2 */
            u8                         instrlen;             /*    10     1 */
            u8                         replacementlen;       /*    11     1 */
            u8                         padlen;               /*    12     1 */

            /* size: 13, cachelines: 1, members: 6 */
            /* last cacheline: 13 bytes */
      } __attribute__((__packed__));
      $ pahole -C alt_instr ~/git/build/v5.7-rc2+/vmlinux <
.altinstructions  | head
      0x90 0xe6 0xe0 0xff 0x73 0x48 0x00 0x00 0x70 0x00 0x05 0x05 0x00,
      0x83 0xe6 0xe0 0xff 0x6b 0x48 0x00 0x00 0x29 0x01 0x05 0x05 0x00,
      0x2a 0x72 0xc5 0xfe 0x63 0x48 0x00 0x00 0xeb 0x00 0x02 0x00 0x00,
      0x22 0x72 0xc5 0xfe 0x56 0x48 0x00 0x00 0x91 0x00 0x05 0x05 0x05,
      0x0c 0x73 0xc5 0xfe 0x4e 0x48 0x00 0x00 0xeb 0x00 0x02 0x00 0x00,
      0x04 0x73 0xc5 0xfe 0x41 0x48 0x00 0x00 0x91 0x00 0x02 0x00 0x00,
      0x72 0x73 0xc5 0xfe 0x34 0x48 0x00 0x00 0xf3 0x00 0x2b 0x2b 0x29,
      0xca 0x73 0xc5 0xfe 0x52 0x48 0x00 0x00 0xec 0x00 0x18 0x18 0x16,
      0xbd 0x73 0xc5 0xfe 0x5d 0x48 0x00 0x00 0xed 0x00 0x18 0x05 0x16,
      0xd3 0x7a 0xc5 0xfe 0x55 0x48 0x00 0x00 0x34 0x01 0x03 0x03 0x03,
      $

    Suggested-by: Joe Lawrence <joe.lawrence@xxxxxxxxxx>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>

 pahole.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)



It seems the output is now only available if it is a real tty, which
doesn't work for my scripts.
So, just as a question: Is this change really intentional?
Is there any easy way to restore the old behavior?

FYI: my scripts are using perl and python, I do no really favor
changing them, but if there is no other way.. I will do it :)

-- Bernd



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux