Re: elf obj load: skip zero-sized sections early
What do you think about something like the following?
diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h
index 1ee7717..ddfdefc 100644
--- a/sys/sys/pcpu.h
+++ b/sys/sys/pcpu.h
@@ -53,14 +53,17 @@
extern uintptr_t *__start_set_pcpu;
extern uintptr_t *__stop_set_pcpu;
-__asm__(
-#ifdef __arm__
- ".section set_pcpu, \"aw\", %progbits\n"
+#if defined(__arm__)
+#define _PROGBITS "%progbits"
#else
- ".section set_pcpu, \"aw\", @progbits\n"
+#define _PROGBITS "@progbits"
#endif
- "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n"
- "\t.previous");
+#define_CUSTOM_SECTION(name, flags, align)
\
+ __asm__(\
+ ".section " __XSTRING(name) \
+ ",\"" __XSTRING(flags) "\"," _PROGBITS "\n" \
+ "\t.p2align " __XSTRING(align) "\n" \
+ "\t.previous")
/*
* Array of dynamic pcpu base offsets. Indexed by id.
@@ -82,7 +85,10 @@ extern uintptr_t dpcpu_off[];
*/
#defineDPCPU_NAME(n) pcpu_entry_##n
#defineDPCPU_DECLARE(t, n) extern t DPCPU_NAME(n)
-#defineDPCPU_DEFINE(t, n) t DPCPU_NAME(n) __section("set_pcpu")
__used
+
+#defineDPCPU_DEFINE(t, n)
\
+ _CUSTOM_SECTION(set_pcpu, aw, CACHE_LINE_SHIFT);\
+ t DPCPU_NAME(n) __section("set_pcpu") __used
/*
* Accessors with a given base.
The diff looks a little bit messier than the resulting macros :-)
So I am pasting them too, just for your convenience:
#if defined(__arm__)
#define _PROGBITS "%progbits"
#else
#define _PROGBITS "@progbits"
#endif
#define _CUSTOM_SECTION(name, flags, align) \
__asm__(\
".section " __XSTRING(name) \
",\"" __XSTRING(flags) "\"," _PROGBITS "\n" \
"\t.p2align " __XSTRING(align) "\n" \
"\t.previous")
...
#define DPCPU_DEFINE(t, n) \
_CUSTOM_SECTION(set_pcpu, aw, CACHE_LINE_SHIFT);\
t DPCPU_NAME(n) __section("set_pcpu") __used
Not sure if _CUSTOM_SECTION is an overkill here or a useful/reusable thing.
The idea is to tie '.section' directive to DPCPU_DEFINE macro, so that [empty]
set_pcpu section is not created by merely including pcpu.h.
Multiple DPCPU_DEFINE instances would cause multiple '.section' directives for
set_pcpu, but that doesn't cause any problem.
Here's an example of how this case looks in gcc-generated assembly (with two
DPCPU_DEFINE instances):
#APP
.sectionset_pcpu,"aw",@progbits
.p2align 7
.previous
.sectionset_pcpu,"aw",@progbits
.p2align 7
.previous
...
#NO_APP
...
.globl pcpu_entry_dpcpu_nvram1
.sectionset_pcpu,"aw",@progbits
.align 8
.type pcpu_entry_dpcpu_nvram1, @object
.size pcpu_entry_dpcpu_nvram1, 8
pcpu_entry_dpcpu_nvram1:
.zero 8
.globl pcpu_entry_dpcpu_nvram2
.align 8
.type pcpu_entry_dpcpu_nvram2, @object
.size pcpu_entry_dpcpu_nvram2, 8
pcpu_entry_dpcpu_nvram2:
.zero 8
.data
...
Here's objdump of the resulting module:
objdump -x -w nvram.ko | fgrep set_pcpu
5 set_pcpu 0010 0380 2**7
CONTENTS, ALLOC, LOAD, DATA
l O set_pcpu 0008 pcpu_entry_dpcpu_nvram1
0008 l O set_pcpu 0008 pcpu_entry_dpcpu_nvram2
ld set_pcpu
Looks good to me.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [Patch] Kgmon/Gprof On/Off Switch
On Tue, 6 Jul 2010, Sean Bruno wrote:
On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote:
Found this lying around the Yahoo tree this week. Basically it allows
you to activate, reset and deactivate profiling with the '-f" flag.
I want something like this, but this implementation has too many style
bugs and obscure or missing locking.
Kind of nice to have if you want the ability to turn on profiling for
debugging live systems.
We already have this via `kgmon -hBb', but this patch implements
something different. Normal profiling requires configuring the kernel
with "config -p[p]", but that adds a lot of overhead, even when profiling
is not turned on. The patch implements dynamic configuration of flat
profiling only (since dynamic call graphs are too hard to implement,
but this restriction is not mentioned anywhere in the patch or the
accompanying mail.
Userland profiling has the same lossage -- you have to configure
programs specially by compiling with -pg, but that adds a lot of
overhead, even when profiling is not turned on. Moreover, in userland
there is no library support for turning profiling on and off or for
dumping and clearing the statistics except on program start and
completion, so the much larger overhead of always maintaining the call
graph is normally always present.
In FreeBSD-1, I (ab)used a bug in the implementation to turn on flat
profiling (only) in the kernel. This avoids the large call graph
overhead (it still costs a function call and some other branches on
every call and maybe on every return, but the branches for this are
predictable so the overhead is not very large. This should be made
a standard feature, and perhaps this patch implements it as a bug
without really trying, as in FreeBSD-1 (implementing it just takes
setting gp->state to a value that gives flat profiling while keeping
mcount() null if full profiling is configured.
% Index: usr.sbin/kgmon/kgmon.8
% ===
% --- usr.sbin/kgmon/kgmon.8(revision 209745)
% +++ usr.sbin/kgmon/kgmon.8(working copy)
% @@ -70,6 +70,9 @@
% Dump the contents of the profile buffers into a
% .Pa gmon.out
% file.
% +.It Fl f
% +Free profiling buffer.
% +Also stops profiling.
% .It Fl r
% Reset all the profile buffers.
% If the
Freeing the profiling buffer alone isn't very useful. The memory wastage
from always allocating it at boot time and never freeing it would be
rarely noticed, and would fix some races or simplify avoidance of races.
However, apart from the race problems, ordinary statically configured
profiling should free things too, since unlike in userland it is normal
to have profiling turned off most of the time even when it is statically
configured.
The above doesn't really describe what -f does. In normal profiling,
there are multiple profiling buffers and freeing just the flat profiling
one makes no sense. -f in fact frees the profiling buffer only if the
kernel is _not_ configured for profiling (as is required to not corrupt
the set of profiling buffers if the kernel is configured for profiling).
The profiling buffer is automatically allocated on first use iff it
is not already allocated, and of course -f has no effect if no buffer
is allocated. Perhaps -r should automatically deallocate, so -f would
not be needed. Kernel profiling has this feature of allowing multiple
dumps of the buffer(s) before reset, so reset is a good time to deallocate.
Style bugs in the above: f is unsorted between p and r.
% Index: usr.sbin/kgmon/kgmon.c
% ===
% --- usr.sbin/kgmon/kgmon.c(revision 209745)
% +++ usr.sbin/kgmon/kgmon.c(working copy)
% @@ -72,7 +72,7 @@
% struct gmonparam gpm;
% };
%
% -int Bflag, bflag, hflag, kflag, rflag, pflag;
% +int Bflag, bflag, hflag, kflag, rflag, pflag, fflag;
Style bugs: now f is unsorted after r and p. p was already unsorted after r.
% int debug = 0;
% int getprof(struct kvmvars *);
% int getprofhz(struct kvmvars *);
% @@ -82,6 +82,7 @@
% void dumpstate(struct kvmvars *kvp);
% void reset(struct kvmvars *kvp);
% static void usage(void);
% +voidfreebuf(struct kvmvars *kvp);
Style bugs: f is unsorted after u; all the old declarations are indented
with 1 tab while the new one is indented with spaces.
%
% int
% main(int argc, char **argv)
% @@ -93,7 +94,7 @@
% seteuid(getuid());
% kmemf = NULL;
% system = NULL;
% - while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) {
% + while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) {
% switch((char)ch) {
%
% case 'M':
% @@ -113,6 +114,10 @@
% bflag = 1;
% break;
%
% + case 'f':
% + fflag = 1;
% + break;
% +
% case 'h':
% hflag = 1;
% break;
Now f is correctly sorted in the above 2 plac
Re: [Patch] Kgmon/Gprof On/Off Switch
On Tue, 2010-07-06 at 17:40 -0700, Bruce Evans wrote:
> On Tue, 6 Jul 2010, Sean Bruno wrote:
>
> > On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote:
> >> Found this lying around the Yahoo tree this week. Basically it allows
> >> you to activate, reset and deactivate profiling with the '-f" flag.
>
> I want something like this, but this implementation has too many style
> bugs and obscure or missing locking.
>
> >> Kind of nice to have if you want the ability to turn on profiling for
> >> debugging live systems.
>
> We already have this via `kgmon -hBb', but this patch implements
> something different. Normal profiling requires configuring the kernel
> with "config -p[p]", but that adds a lot of overhead, even when profiling
> is not turned on. The patch implements dynamic configuration of flat
> profiling only (since dynamic call graphs are too hard to implement,
> but this restriction is not mentioned anywhere in the patch or the
> accompanying mail.
>
> Userland profiling has the same lossage -- you have to configure
> programs specially by compiling with -pg, but that adds a lot of
> overhead, even when profiling is not turned on. Moreover, in userland
> there is no library support for turning profiling on and off or for
> dumping and clearing the statistics except on program start and
> completion, so the much larger overhead of always maintaining the call
> graph is normally always present.
>
> In FreeBSD-1, I (ab)used a bug in the implementation to turn on flat
> profiling (only) in the kernel. This avoids the large call graph
> overhead (it still costs a function call and some other branches on
> every call and maybe on every return, but the branches for this are
> predictable so the overhead is not very large. This should be made
> a standard feature, and perhaps this patch implements it as a bug
> without really trying, as in FreeBSD-1 (implementing it just takes
> setting gp->state to a value that gives flat profiling while keeping
> mcount() null if full profiling is configured.
>
> % Index: usr.sbin/kgmon/kgmon.8
> % ===
> % --- usr.sbin/kgmon/kgmon.8(revision 209745)
> % +++ usr.sbin/kgmon/kgmon.8(working copy)
> % @@ -70,6 +70,9 @@
> % Dump the contents of the profile buffers into a
> % .Pa gmon.out
> % file.
> % +.It Fl f
> % +Free profiling buffer.
> % +Also stops profiling.
> % .It Fl r
> % Reset all the profile buffers.
> % If the
>
> Freeing the profiling buffer alone isn't very useful. The memory wastage
> from always allocating it at boot time and never freeing it would be
> rarely noticed, and would fix some races or simplify avoidance of races.
> However, apart from the race problems, ordinary statically configured
> profiling should free things too, since unlike in userland it is normal
> to have profiling turned off most of the time even when it is statically
> configured.
>
> The above doesn't really describe what -f does. In normal profiling,
> there are multiple profiling buffers and freeing just the flat profiling
> one makes no sense. -f in fact frees the profiling buffer only if the
> kernel is _not_ configured for profiling (as is required to not corrupt
> the set of profiling buffers if the kernel is configured for profiling).
> The profiling buffer is automatically allocated on first use iff it
> is not already allocated, and of course -f has no effect if no buffer
> is allocated. Perhaps -r should automatically deallocate, so -f would
> not be needed. Kernel profiling has this feature of allowing multiple
> dumps of the buffer(s) before reset, so reset is a good time to deallocate.
>
> Style bugs in the above: f is unsorted between p and r.
>
> % Index: usr.sbin/kgmon/kgmon.c
> % ===
> % --- usr.sbin/kgmon/kgmon.c(revision 209745)
> % +++ usr.sbin/kgmon/kgmon.c(working copy)
> % @@ -72,7 +72,7 @@
> % struct gmonparam gpm;
> % };
> %
> % -int Bflag, bflag, hflag, kflag, rflag, pflag;
> % +int Bflag, bflag, hflag, kflag, rflag, pflag, fflag;
>
> Style bugs: now f is unsorted after r and p. p was already unsorted after r.
>
> % int debug = 0;
> % int getprof(struct kvmvars *);
> % int getprofhz(struct kvmvars *);
> % @@ -82,6 +82,7 @@
> % void dumpstate(struct kvmvars *kvp);
> % void reset(struct kvmvars *kvp);
> % static void usage(void);
> % +voidfreebuf(struct kvmvars *kvp);
>
> Style bugs: f is unsorted after u; all the old declarations are indented
> with 1 tab while the new one is indented with spaces.
>
> %
> % int
> % main(int argc, char **argv)
> % @@ -93,7 +94,7 @@
> % seteuid(getuid());
> % kmemf = NULL;
> % system = NULL;
> % - while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) {
> % + while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) {
> % switch((char)ch) {
> %
> % case 'M':
> % @@ -113,6 +114,10 @@
>
envy24 driver broken
Hello. Is anyone using the envy24 audio driver? I've tried it with two cards (M-Audio Delta 66, M-Audio Audiophile) and it just doesn't work properly. Both are claimed to be supported and yet they spew errors to the console on boot: WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured etc. I can get audio out (most of the time) but only on two channels despite the Delta 66 being a six channel card. I can't get audio in at all. It seems like the driver's not been updated for over a year and that nobody really seems to be interested in the fact that it doesn't work. Any assistance would be appreciated (or recommendations for "pro" audio hardware that actually works with freebsd). Regards, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: envy24 driver broken
On 7 July 2010 22:39, wrote: > Hello. > > Is anyone using the envy24 audio driver? > > I've tried it with two cards (M-Audio Delta 66, M-Audio Audiophile) > and it just doesn't work properly. Both are claimed to be supported > and yet they spew errors to the console on boot: > > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > > etc. > > I can get audio out (most of the time) but only on two channels despite > the Delta 66 being a six channel card. I can't get audio in at all. > > It seems like the driver's not been updated for over a year and that > nobody really seems to be interested in the fact that it doesn't work. > > Any assistance would be appreciated (or recommendations for "pro" audio > hardware that actually works with freebsd). > > Regards, > xw Hi! I have audiophile192 card, it uses a different envy24ht (not envy24), but with the same mixer warnings you described above. I saw these warning since time driver has been committed to the tree. -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: envy24 driver broken
On 2010-07-07 22:50:14, pluknet wrote: > > Hi! > > I have audiophile192 card, it uses a different envy24ht (not envy24), > but with the same mixer warnings you described above. > I saw these warning since time driver has been committed to the tree. Hi, Does the card actually work? Can you get audio input and output (and both at the same time, full duplex?) Regards, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: envy24 driver broken
On 7 July 2010 22:58, wrote: > On 2010-07-07 22:50:14, pluknet wrote: >> >> Hi! >> >> I have audiophile192 card, it uses a different envy24ht (not envy24), >> but with the same mixer warnings you described above. >> I saw these warning since time driver has been committed to the tree. > > Hi, > > Does the card actually work? > > Can you get audio input and output (and both at the same time, > full duplex?) > I just tried 2ch output. -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
