Thanks Konstantin, yeah I think there were two levels of strip
happening, one removing the debug sections and another
was removing the .strtab and .symtab. I have EXPORT_SYMS = YES in my
Makefile but that was not helping as the
variables in context are declared static (they are going into the
.bss)
On Wed, Dec 05, 2012 at 12:13:24PM +0530, Shrikanth Kamath wrote:
> This is regarding the fields in the structure "elf_file_t" in link_elf.c.
> For some kernel modules the symtab field is different from the ddbsymtab
> field for some it is the same, would like to know what is the difference
> betwe
on 12/07/2010 00:38 Andriy Gapon said the following:
> on 12/07/2010 00:15 Jeff Roberson said the following:
[snip]
>> I appreciate your analysis but I don't understand the motivation for
>> changing working code.
>
> Primary reason is that the "working code" produces zero-sized
> unused/unnecess
On Sun, 11 Jul 2010, Andriy Gapon wrote:
[oops, sorry, this is not a dup - corrected some omissions/mistakes]
on 11/07/2010 14:54 Andriy Gapon said the following:
For completeness, here is a patch that simply drops the inline assembly and the
comment about it, and GCC-generated assembly and
on 12/07/2010 00:15 Jeff Roberson said the following:
>
> On Sun, 11 Jul 2010, Andriy Gapon wrote:
>
>>
>> [oops, sorry, this is not a dup - corrected some omissions/mistakes]
>>
>> on 11/07/2010 14:54 Andriy Gapon said the following:
>>> For completeness, here is a patch that simply drops the in
[oops, sorry, this is not a dup - corrected some omissions/mistakes]
on 11/07/2010 14:54 Andriy Gapon said the following:
> For completeness, here is a patch that simply drops the inline assembly and
> the
> comment about it, and GCC-generated assembly and its diff:
> http://people.freebsd.org/~
on 11/07/2010 14:54 Andriy Gapon said the following:
> For completeness, here is a patch that simply drops the inline assembly and
> the
> comment about it, and GCC-generated assembly and its diff:
> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
> http://people.freebsd.org/~avg/dpcpu/dpcpu.n
on 09/07/2010 13:34 Andriy Gapon said the following:
> Having thought and experimented more, I don't see why we need inline assembly
> at
> all and why DPCPU_DEFINE can not simply be defined as follows:
>
> #define DPCPU_DEFINE(t, n)\
> t DPCPU_NAME(n) __section("set_pcpu") \
> __
Having thought and experimented more, I don't see why we need inline assembly at
all and why DPCPU_DEFINE can not simply be defined as follows:
#define DPCPU_DEFINE(t, n) \
t DPCPU_NAME(n) __section("set_pcpu") \
__aligned(CACHE_LINE_SIZE) __used
And, honestly, I can not und
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__
-
On 7/5/10 10:12 AM, Bjoern A. Zeeb wrote:
On Mon, 5 Jul 2010, Andriy Gapon wrote:
[...]
The same applies to VIMAGE btw. Same technique.
or the proposed per-vimage AND per-CPU zone (to allow pcpu stats in a
vimage..).. which degenerates to just more pcpu stuff if vimage is not
enabled.
on 05/07/2010 20:12 Bjoern A. Zeeb said the following:
> On Mon, 5 Jul 2010, Andriy Gapon wrote:
>
>> on 02/07/2010 11:29 Bjoern A. Zeeb said the following:
>>> On Fri, 25 Jun 2010, Andriy Gapon wrote:
>>>
>>> Hey,
>>>
Proposed patch skips zero sized sections without going into trouble of
>>>
On Mon, 5 Jul 2010, Andriy Gapon wrote:
on 02/07/2010 11:29 Bjoern A. Zeeb said the following:
On Fri, 25 Jun 2010, Andriy Gapon wrote:
Hey,
Proposed patch skips zero sized sections without going into trouble of
allocating section entry (progtab), doing zero-sized memory allocs and
copies.
I
on 02/07/2010 11:29 Bjoern A. Zeeb said the following:
> On Fri, 25 Jun 2010, Andriy Gapon wrote:
>
> Hey,
>
>> Proposed patch skips zero sized sections without going into trouble of
>> allocating section entry (progtab), doing zero-sized memory allocs and
>> copies.
>> I observe that sometimes z
On Fri, 25 Jun 2010, Andriy Gapon wrote:
Hey,
Proposed patch skips zero sized sections without going into trouble of
allocating section entry (progtab), doing zero-sized memory allocs and copies.
I observe that sometimes zero-sized set_pcpu sections are produced in module
objects, maybe when a
On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote:
> I have this error message when i'm wanting to start mozilla for example. Do
> some of you know whats wrong and what I can do to get it working again?
>
> Wouter van Rooij
Hey Wouter,
you should have just aske
On Fri, 16 Sep 2005, Peter Pentchev wrote:
>
> What is weird? The fact that if linux.ko is not loaded, the kernel
> does not know what to do with an unknown ELF binary type? :)
>
> What I find weird is the fact that as soon as linux.ko is loaded,
> the kernel "learns" to treat type 0 binaries as t
On Saturday 17 September 2005 00:16, Peter Pentchev wrote:
> > Wow that's weird..
> > I wonder why that happens?
>
> What is weird? The fact that if linux.ko is not loaded, the kernel
> does not know what to do with an unknown ELF binary type? :)
I misread that as having linprocfs loaded :)
> Wh
On Fri, Sep 16, 2005 at 11:57:21PM +0930, Daniel O'Connor wrote:
> On Friday 16 September 2005 23:42, Daniel Eischen wrote:
> > > I'd be *very* suprised..
> > > I expect he just downloaded an RPM from somewhere..
> >
> > It's probably just not having linux.ko/linprocfs.ko loaded.
> >
> > $ kldsta
On Friday 16 September 2005 23:42, Daniel Eischen wrote:
> > I'd be *very* suprised..
> > I expect he just downloaded an RPM from somewhere..
>
> It's probably just not having linux.ko/linprocfs.ko loaded.
>
> $ kldstat
> Id Refs AddressSize Name
>11 0xc040 498518 kernel
>
On Fri, 16 Sep 2005, Daniel O'Connor wrote:
> On Friday 16 September 2005 23:26, Peter Pentchev wrote:
> > Yep, I think this probably takes care of step 1 and possibly 3b, although
> > the message that Wouter gets is making me think that for some reason
> > the port has *not* run brandelf on the e
On Friday 16 September 2005 23:26, Peter Pentchev wrote:
> Yep, I think this probably takes care of step 1 and possibly 3b, although
> the message that Wouter gets is making me think that for some reason
> the port has *not* run brandelf on the executables - if brandelf had been
> run, wouldn't the
On Fri, Sep 16, 2005 at 11:07:31PM +0930, Daniel O'Connor wrote:
> On Friday 16 September 2005 22:53, Peter Pentchev wrote:
> > On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote:
> > > I have this error message when i'm wanting to start mozilla for example.
> > > Do some of you know
On Friday 16 September 2005 22:53, Peter Pentchev wrote:
> On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote:
> > I have this error message when i'm wanting to start mozilla for example.
> > Do some of you know whats wrong and what I can do to get it working
> > again?
>
> Is this a
On Fri, Sep 16, 2005 at 03:18:05PM +0200, Joerg Sonnenberger wrote:
> On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote:
> > I have this error message when i'm wanting to start mozilla for example. Do
> > some of you know whats wrong and what I can do to get it working again?
>
> I
On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote:
> I have this error message when i'm wanting to start mozilla for example. Do
> some of you know whats wrong and what I can do to get it working again?
Is it by any chance a Linux binary? Try brandelf in that case. Well, try
brande
On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote:
> I have this error message when i'm wanting to start mozilla for example. Do
> some of you know whats wrong and what I can do to get it working again?
Is this a Linux binary of Mozilla? If you are trying to run a Linux
applicatio
On Thu, Feb 05, 2004 at 10:31:54AM +, Philip Reynolds wrote:
> Ruslan Ermilov <[EMAIL PROTECTED]> 35 lines of wisdom included:
> > On Thu, Feb 05, 2004 at 08:39:45AM +, Philip Reynolds wrote:
> > [...]
> > > Does the magic number not then support multiple ABI's per system
> > > architecture
In message: <[EMAIL PROTECTED]>
Philip Reynolds <[EMAIL PROTECTED]> writes:
: Ruslan Ermilov <[EMAIL PROTECTED]> 35 lines of wisdom included:
: > On Thu, Feb 05, 2004 at 08:39:45AM +, Philip Reynolds wrote:
: > [...]
: > > Does the magic number not then support multiple ABI's per sy
Ruslan Ermilov <[EMAIL PROTECTED]> 35 lines of wisdom included:
> On Thu, Feb 05, 2004 at 08:39:45AM +, Philip Reynolds wrote:
> [...]
> > Does the magic number not then support multiple ABI's per system
> > architecture, or is there some part of the puzzle I'm missing?
> >
> There's an EI_ABI
On Thu, Feb 05, 2004 at 08:39:45AM +, Philip Reynolds wrote:
[...]
> Does the magic number not then support multiple ABI's per system
> architecture, or is there some part of the puzzle I'm missing?
>
There's an EI_ABIVERSION byte following the EI_OSABI byte, which
is both documented in the el
In article <[EMAIL PROTECTED]>,
milunovic <[EMAIL PROTECTED]> wrote:
>
> I'm little confused.I'm reading ELF specification and I found that
> p_offset and p_vaddr should be congrunet to module PAGE_SIZE.
> So is this correct ? If it isn't can anybody tell me what is correct.
It is correct. It
Julian Stacey wrote:
>
> Ollivier Robert wrote:
> > According to Julian Stacey:
> > > 4.1-release produces no /sbin/mount_cfs, & man mount give no hint,
> > > If you have patches to test, I volunteer to test on 4.1 or 3.4 :-)
> > It is a port. I'd love to import it into CURRENT though.
>
> Some
Ollivier Robert wrote:
> According to Julian Stacey:
> > 4.1-release produces no /sbin/mount_cfs, & man mount give no hint,
> > If you have patches to test, I volunteer to test on 4.1 or 3.4 :-)
> It is a port. I'd love to import it into CURRENT though.
Some friends running vile Micro$oft asked m
According to Julian Stacey:
> 4.1-release produces no /sbin/mount_cfs, & man mount give no hint,
> If you have patches to test, I volunteer to test on 4.1 or 3.4 :-)
It is a port. I'd love to import it into CURRENT though.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
Ollivier Robert wrote:
> According to Julian Stacey:
> > just as today I'd use an encrypting file system on my new laptop,
> > but such file system don't exist on FreeBSD unfortunately.
>
> Ahem. Why did I sent an update for security/cfs to green a few months ago? :-)
4.1-release produces no /sb
According to Julian Stacey:
> just as today I'd use an encrypting file system on my new laptop,
> but such file system don't exist on FreeBSD unfortunately.
Ahem. Why did I sent an update for security/cfs to green a few months ago? :-)
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMA
"Andrew Reilly" wrote:
> Well, even if there are/were folk who want tiny disk footprints,
> and crunching everything isn't going to do the whole job, wouldn't
> a compressed filesystem be a better way to approach this? At least
> that way you'd still be able to page from the executable(s), and
>
On Wed, 26 Jul 2000, Julian Stacey wrote:
> That laptop has now gone to 4.0, & aout to elf, & a 1.5G disc, so no
> incentive to do it all again to see how much FreeBSD-4 gzipped aout
> binary tree might save/waste on a whole tree. BTW I was `strip'ing
gzexe(1) is your friend :-)
Kris
--
In Go
On Wed, Jul 26, 2000 at 02:00:46PM -0600, Nate Williams wrote:
> > No, that's the one case where they help. But people aren't trying to
> > squeeze whole systems into small disks anymore;
>
> Really? News to me...
Well, even if there are/were folk who want tiny disk footprints,
and crunching
In message <[EMAIL PROTECTED]> Mike Smith writes:
: Typically, the loss of the ability to demand-page from a gzipped
: executable is a worse detracting factor than the space saving makes up
: for.
This is one reason that Timing Solutions runs all of its small systems
out of uncompressed flash o
> > Mike Smith wrote:
> > > gzipped binaries are actually a terrible idea; they actually *waste*
> > > space in most cases.
> >
> > Suprising, They saved space for a 200M disc in a 486 laptop with 3.[2,3,or4],
>
> No, that's the one case where they help. But people aren't trying to
> squeeze
> > From: Mike Smith <[EMAIL PROTECTED]>
> Mike Smith wrote:
> > gzipped binaries are actually a terrible idea; they actually *waste*
> > space in most cases.
>
> Suprising, They saved space for a 200M disc in a 486 laptop with 3.[2,3,or4],
No, that's the one case where they hel
> From: Mike Smith <[EMAIL PROTECTED]>
Mike Smith wrote:
> gzipped binaries are actually a terrible idea; they actually *waste*
> space in most cases.
Suprising, They saved space for a 200M disc in a 486 laptop with 3.[2,3,or4],
it was so tight for space I gzipped everything, (entire o
> > From: John Polstra <[EMAIL PROTECTED]>
> > No, there isn't. I don't plan to do anything more with the a.out
> > dynamic linker, as I consider it obsolete at this point. I'd
>
> BTW (last I looked) support of gzipped execs was only available for aout, not
> for elf, ... one more residual use
> From: John Polstra <[EMAIL PROTECTED]>
> No, there isn't. I don't plan to do anything more with the a.out
> dynamic linker, as I consider it obsolete at this point. I'd
BTW (last I looked) support of gzipped execs was only available for aout, not
for elf, ... one more residual use for aout, (
> Besides, have you even established that dynamically linked programs
> load too slowly? I've certainly never heard any complaints along
> those lines. Furthermore I would bet that the bulk of the dynamic
> linking time comes from opening the shared libraries and mmapping
> them, and there's not
In article <[EMAIL PROTECTED]>,
Alex Zepeda <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Jul 2000, John Polstra wrote:
>
> > FreeBSD ELF: It's required by the ELF specification.
> >
> > FreeBSD a.out: Backward compatibility.
> >
> > Linux ELF: Because it's part of Linux and that's just
On Mon, 24 Jul 2000, John Polstra wrote:
> Glad you liked the idea! :-)
Well imagine if Joe user gets a Linux binary or a.out binary to run.
Bam, it doesn't run, and one'd have to check each file, and unset the
variables. Or forgo any user-feedback. :(
> Well, there is a different reason fo
In article <[EMAIL PROTECTED]>,
Alex Zepeda <[EMAIL PROTECTED]> wrote:
>
> Uck.
Glad you liked the idea! :-)
> I'm curious, why do a.out/FreeBSD-elf/Linux-elf programs all respond to
> the same variables? Sure it's perhaps a consistant interface, but
> wouldn't somthing like LINUX_LD_LIBRARY_
On Mon, 24 Jul 2000, John Polstra wrote:
> No, there isn't. I don't plan to do anything more with the a.out
> dynamic linker, as I consider it obsolete at this point. I'd
> suggest making a script "run_aout" that looks something like this
> (untested):
Uck.
> BTW, it's generally not a good id
On Mon, Jul 24, 2000 at 03:25:07AM -0700, Alex Zepeda wrote:
> you're like me and still somewhat attached to the idea of using Navigator
> which is an a.out binary (perhaps the only one I still have left), you're
Use the BSDI Netscape ports, which are ELF and don't require any
emulation. They ar
In article <[EMAIL PROTECTED]>,
Alex Zepeda <[EMAIL PROTECTED]> wrote:
[LD_PRELOAD and LD_LIBRARY_PATH]
> This works great if you're using your average ELF binary. However, if
> you're like me and still somewhat attached to the idea of using Navigator
> which is an a.out binary (perhaps the onl
Marco van de Voort wrote:
>
> How can I disassemble ELF programs?
objdump --disassemble
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
[EMAIL PROTECTED]
>
> On 04-Feb-00 Marco van de Voort wrote:
> >
> >
> > How can I disassemble ELF programs?
> >
> > I need to create my own startup code for FPC programs.
> > (copying some variables before pascal code startup)
>
> Try 'objdump -d'. It's more readable if you don't strip the program.
> You ca
On Fri, 4 Feb 2000, John Baldwin wrote:
>
> On 04-Feb-00 Marco van de Voort wrote:
> >
> >
> > How can I disassemble ELF programs?
> >
> > I need to create my own startup code for FPC programs.
> > (copying some variables before pascal code startup)
>
> Try 'objdump -d'. It's more readable
On 04-Feb-00 Marco van de Voort wrote:
>
>
> How can I disassemble ELF programs?
>
> I need to create my own startup code for FPC programs.
> (copying some variables before pascal code startup)
Try 'objdump -d'. It's more readable if you don't strip the program.
You can also use this to dis
Marco van de Voort <[EMAIL PROTECTED]> wrote:
>How can I disassemble ELF programs?
Try IDA PRO :
http://www.datarescue.com/ida.htm
http://www.rosprombank.ru/~ig/
--
-=AV=-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
>
> > The big benefits to locality of meta & file data are to allow
> > drive/driver caching to do sequential (or close to) reads in as large
> > blocks as possible. There was a recent SigOS paper on a modified Unix
> > filesystem that was designed to take advantage of modern disk systems,
>
> The big benefits to locality of meta & file data are to allow
> drive/driver caching to do sequential (or close to) reads in as large
> blocks as possible. There was a recent SigOS paper on a modified Unix
> filesystem that was designed to take advantage of modern disk systems,
Do you st
Matthew Dillon <[EMAIL PROTECTED]> writes:
>:> distribute the inodes all over the cylinder group rather then concentrate
>:> all the inodes in one place.
>:
>:Yes. I have implemented most of the code. I noticed the "ls -al" is slow
>:but "ls" is OK.
>
>Yes, ls (without any options) is ok bec
Matthew Dillon <[EMAIL PROTECTED]> writes:
>:On Mon, 6 Dec 1999, Zhihui Zhang wrote:
>:> I have modified FFS filesystem code to put the disk inode at the beginning
>:> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
>:> its disk inode and the rest of it are file data.
>
:> distribute the inodes all over the cylinder group rather then concentrate
:> all the inodes in one place.
:
:Yes. I have implemented most of the code. I noticed the "ls -al" is slow
:but "ls" is OK.
Yes, ls (without any options) is ok because the file type is now being
stuffe
On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > I am doing some research on filesystem. I guess it may be faster to put
> > the disk inode with its file data together so that both can be read into
> > memory in one I/O.
>
> I still don't get it. To g
In message <[EMAIL PROTECTED]>, "Ronal
d G. Minnich" writes:
>On Mon, 6 Dec 1999, Zhihui Zhang wrote:
>> I am doing some research on filesystem. I guess it may be faster to put
>> the disk inode with its file data together so that both can be read into
>> memory in one I/O.
>
>I still don't get
On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> I am doing some research on filesystem. I guess it may be faster to put
> the disk inode with its file data together so that both can be read into
> memory in one I/O.
I still don't get it. To get the file, you do a lookup. So the inode is in
memory. Th
On Mon, 6 Dec 1999, Matthew Dillon wrote:
> :On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> :
> :> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> :> > I have modified FFS filesystem code to put the disk inode at the beginning
> :> > of a file, i.e, the logical block #0 of each file begins with 128 b
On Mon, 6 Dec 1999, Julian Elischer wrote:
> how do you find the inode?
There is an inode address map to look up. Each entry is four bytes.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Mon, 6 Dec 1999, Matthew Dillon wrote:
> :On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> :
> :> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> :> > I have modified FFS filesystem code to put the disk inode at the beginning
> :> > of a file, i.e, the logical block #0 of each file begins with 128 by
how do you find the inode?
On Mon, 6 Dec 1999, Zhihui Zhang wrote:
>
> On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
>
> > On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > > I have modified FFS filesystem code to put the disk inode at the beginning
> > > of a file, i.e, the logical block #0 of eac
:On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
:
:> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
:> > I have modified FFS filesystem code to put the disk inode at the beginning
:> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
:> > its disk inode and the rest of it are file
:On Mon, 6 Dec 1999, Zhihui Zhang wrote:
:> I have modified FFS filesystem code to put the disk inode at the beginning
:> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
:> its disk inode and the rest of it are file data.
:
:first question I have is, why?
:
:ron
Go
On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > I have modified FFS filesystem code to put the disk inode at the beginning
> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> > its disk inode and the rest of it are file data
On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> I have modified FFS filesystem code to put the disk inode at the beginning
> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> its disk inode and the rest of it are file data.
first question I have is, why?
ron
To Unsubscri
74 matches
Mail list logo
