public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug bpf/24358] New: 32-bit stapbpf: could not find _stext in /proc/kallsyms
@ 2019-03-18 15:28 me at serhei dot io
  2019-03-18 16:09 ` [Bug bpf/24358] 32-bit stapbpf: things need fixing re: (void *) use in libbpf and elsewhere me at serhei dot io
  0 siblings, 1 reply; 2+ messages in thread
From: me at serhei dot io @ 2019-03-18 15:28 UTC (permalink / raw)
  To: systemtap

https://sourceware.org/bugzilla/show_bug.cgi?id=24358

            Bug ID: 24358
           Summary: 32-bit stapbpf: could not find _stext in
                    /proc/kallsyms
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: bpf
          Assignee: systemtap at sourceware dot org
          Reporter: me at serhei dot io
  Target Milestone: ---

Host: Linux stap-f28-32.local 4.20.5-100.fc28.i686 #1 SMP Mon Jan 28 19:34:15
UTC 2019 i686 i686 i386 GNU/Linux
Snapshot: version 4.1/0.174, commit release-4.0-97-g6b0430b6b2ba

Also seen on kernel 4.18.16, f29

spawn stap -v --runtime=bpf
/notnfs/smakarov/stap-checkout/testsuite/systemtap.bpf/bpf_tests/array.stp
Pass 1: parsed user script and 49 library scripts using
31736virt/16064res/7212shr/8832data kb, in 20usr/0sys/40real ms.
Pass 2: analyzed script: 5 probes, 3 functions, 0 embeds, 1 global using
64872virt/50208res/8168shr/41968data kb, in 1450usr/50sys/1$
Pass 4: compiled BPF into "stap_4963.bo" in 0usr/0sys/4real ms.
Pass 5: starting run.
Error loading /tmp/stap130KEQ/stap_4963.bo: could not find _stext in
/proc/kallsymsWARNING: /notnfs/smakarov/stap-checkout/stap_inst$
Pass 5: run completed in 10usr/70sys/94real ms.
Pass 5: run failed.  [man error::pass5]
Executing: kill -INT -4963

Probably related to pr21891

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug bpf/24358] 32-bit stapbpf: things need fixing re: (void *) use in libbpf and elsewhere
  2019-03-18 15:28 [Bug bpf/24358] New: 32-bit stapbpf: could not find _stext in /proc/kallsyms me at serhei dot io
@ 2019-03-18 16:09 ` me at serhei dot io
  0 siblings, 0 replies; 2+ messages in thread
From: me at serhei dot io @ 2019-03-18 16:09 UTC (permalink / raw)
  To: systemtap

https://sourceware.org/bugzilla/show_bug.cgi?id=24358

Serhei Makarov <me at serhei dot io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|32-bit stapbpf: could not   |32-bit stapbpf: things need
                   |find _stext in              |fixing re: (void *) use in
                   |/proc/kallsyms              |libbpf and elsewhere

--- Comment #1 from Serhei Makarov <me at serhei dot io> ---
In principle, we want to add 32-bit support. (Currently there is no 32-bit
Fedora bcc package either.)

The kallsyms parsing code in stapbpf.cxx had been hardcoded in a way that only
works on 64-bit architectures. This is an easy fix, but unmasks a whole range
of other issues that block stapbpf from working on 32-bit. Lots of code in
libbpf assumes void* is interchangeable with __u64, which leads to 'stack
smashing' errors on map read/write system calls. 

Up to now, serious testing/qa for stapbpf has targeted x86_64, which is why
this issue came up only when I went to make serious transport changes and
decided these merited checking for regressions on other architectures.

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-03-18 16:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-18 15:28 [Bug bpf/24358] New: 32-bit stapbpf: could not find _stext in /proc/kallsyms me at serhei dot io
2019-03-18 16:09 ` [Bug bpf/24358] 32-bit stapbpf: things need fixing re: (void *) use in libbpf and elsewhere me at serhei dot io

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).