GSOC candidature draft for urgent feedback

[enh]

actually, -y was my biggest wish-list feature :-)

other things i've hated doing manually in the past include working out
exactly what a given socket is (usually "what's the remote address?").
pipes too. in both cases the default /proc format is somewhat helpful
but really only the first piece of the puzzle if you actually want to
know what's on the other end.

i asked around, and our kernel guys said support for the
android-specific ioctls would be nice, especially now there's -y (i
only upgraded Android to 4.7 and 4.8 very recently, so this stuff's
all still exciting and new to us!).

one reason we've lagged behind upstream in the past is that we've
needed a lot of local hacks. some bionic's fault, some strace's. as
part of the recent upgrade i fixed the stuff that was bionic's fault,
and it looks like you've already fixed all the stuff on your side. i
still have local hacks for PTRACE_PEEKUSER but they look like they're
fixed at your head and i just need to wait for 4.9. the only remaining
diff i have is that bionic doesn't have <scsi/sg.h> so we can't build
scsi.c which means we can't refer to it in ioctl.c:

+#ifndef HAVE_ANDROID_OS
  case 0x22:
  return scsi_ioctl(tcp, code, arg);
+#endif

if you could add a configure "HAVE_SCSI_SG_H" or somesuch, i think we
could have no local diffs relative to 4.9. (for a while now i've been
asking people who submit fixes to us to submit them to you instead,
and then we cherrypick. chris.dearman's struct sigaction dumping fixes
were the most recent example.)

[full disclosure: i actually have a handful of other hacks in the makefile:
# bionic doesn't have fputs_unlocked.
LOCAL_CFLAGS += -Dfputs_unlocked=fputs
# bionic doesn't have fopen64.
LOCAL_CFLAGS += -Dfopen64=fopen
# uapi's asm/sigcontext.h doesn't have sigcontext_struct.
LOCAL_CFLAGS += -Dsigcontext_struct=sigcontext
i could trivially add the last of these (and probably should), but our
stdio is actually just OpenBSD's, and BSD was smart enough not to have
a 32-bit off_t, so they don't have all the LFS64 crap. i think we're
stuck with that hack until one fine day when we can retire LP32. they
don't have the _unlocked stdio stuff either.
]

anyway, getting back on topic... looking at your list of suggested
projects online, the multi-arch support is something that's going to
be increasingly interesting to us. (other than the clone argument
order bug i mentioned on the list a few months ago, x86/x86_64 works
well enough for me, but i haven't investigated the arm/aarch64 and
mips/mips64 status yet.)

your -yy suggestion sounds useful too, though we haven't had -y long
enough to have any reason to complain yet :-)

On Tue, Feb 18, 2014 at 6:12 AM, Philippe Ombredanne
<pombredanne at nexb.com> wrote:
> On Fri, Feb 14, 2014 at 6:11 PM, enh <enh at google.com> wrote:
>> Feel free to add me. I maintain bionic's C library and use strace pretty
>> much every day.
>
> As a heavy strace user, do you have any wish list that could make your
> usage easier?
> --
> Philippe Ombredanne
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Strace-devel mailing list
> Strace-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.