From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Doug Evans <xdje42@gmail.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Improve and fix catch-syscall.exp
Date: Mon, 16 Dec 2013 04:20:00 -0000 [thread overview]
Message-ID: <m34n694ebq.fsf@redhat.com> (raw)
In-Reply-To: <m3a9g27yr8.fsf@sspiff.org> (Doug Evans's message of "Sun, 15 Dec 2013 10:30:35 -0800")
On Sunday, December 15 2013, Doug Evans wrote:
> Hi.
>
> I was wondering, what if the magic numbers that are the syscall
> numbers were recorded in the test .c file like:
>
> int close_syscall_number = foo;
>
> and then have the .exp fetch these values after running-to-main.
> That would save having to record syscall numbers in the .exp,
> and all the conditionals to test for the architecture.
But then we'd have to make the conditionals on the .c file instead,
right? I mean, we'd just be switching the place of the problem...
> Not sure there isn't a flaw in this plan,
> and I guess it's debatable whether it's better to just record
> the numbers in the .exp or reference the __NR_* numbers from asm/unistd*.h
> in the .c, but it sounds promising.
The .exp file needs to know the syscall numbers (not only the names) in
order to compare them with the output of "catch syscall". Therefore,
just referencing the syscalls as __NR_* won't help with that...
Unless I'm missing something in your proposal, I don't see how it could
improve the current situation.
--
Sergio
next prev parent reply other threads:[~2013-12-16 4:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 23:06 Sergio Durigan Junior
2013-12-15 18:31 ` Doug Evans
2013-12-15 18:44 ` Doug Evans
2013-12-16 4:24 ` Sergio Durigan Junior
2013-12-16 4:20 ` Sergio Durigan Junior [this message]
2013-12-16 23:09 ` Sergio Durigan Junior
2013-12-17 10:24 ` Pedro Alves
2013-12-17 17:35 ` Sergio Durigan Junior
2013-12-18 21:10 ` Doug Evans
2013-12-18 22:26 ` Sergio Durigan Junior
2013-12-16 17:50 ` Pedro Alves
2013-12-16 17:59 ` Sergio Durigan Junior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m34n694ebq.fsf@redhat.com \
--to=sergiodj@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=xdje42@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox