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
between
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
Hi all,
I've a generic question about how the program looks before and after it is
loaded into the memory.
I see that the TEXT_START_ADDR = 0x08048000 (found this in
~src/contrib/binutils/ld/emulparams/elf_i386.sh)
when I do a procstat -v PID, I see some thing like this
PIDSTART
not necessarily the only
thing.
readelf command is quite handy when you need to see details of an ELF file.
But when I do a objdump of /bin/cat (cmd: `objdump -D /bin/cat`), I see
that there is a section named `.interp` starting at 0x8048134 and not
0x8048000. And the .text section starts from
0x00102508 in _start
() #7 0x4022719c in .rtld_start ()
at
/usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
#8 0x4022719c in .rtld_start ()
at
/usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
in __do_global_ctors_aux ()
#5 0x0010243c in _init ()
#6 0x00102508 in _start ()
#7 0x4022719c in .rtld_start ()
at
/usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
#8 0x4022719c in .rtld_start ()
at
/usr/home
/marius/co/head/src/sbin/ifconfig/ifclone.c:106
#4 0x00119864 in __do_global_ctors_aux ()
#5 0x0010243c in _init ()
#6 0x00102508 in _start ()
#7 0x4022719c in .rtld_start ()
at
/usr/home/marius/co/head/src/libexec/rtld-elf/sparc64
/src/sbin/ifconfig/ifclone.c:106
#4 0x00119864 in __do_global_ctors_aux ()
#5 0x0010243c in _init ()
#6 0x00102508 in _start ()
#7 0x4022719c in .rtld_start ()
at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
#8 0x4022719c
0x0010243c in _init ()
#6 0x00102508 in _start ()
#7 0x4022719c in .rtld_start ()
at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
#8 0x4022719c in .rtld_start ()
at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
()
at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
#8 0x4022719c in .rtld_start ()
at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59
Previous frame identical to this frame (corrupt stack?)
All faults I've looked at died
On Fri, Aug 06, 2010 at 07:06:33AM +0200, Jeremie Le Hen wrote:
Hi Kib,
In-Reply-To: 20100629083901.gg13...@deviant.kiev.zoral.com.ua
On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote:
On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote:
On Mon, Jun 28, 2010 at
On Fri, Aug 06, 2010 at 01:08:08PM +0200, Marius Strobl wrote:
On Fri, Aug 06, 2010 at 12:04:04PM +0300, Kostik Belousov wrote:
On Fri, Aug 06, 2010 at 07:06:33AM +0200, Jeremie Le Hen wrote:
Hi Kib,
In-Reply-To: 20100629083901.gg13...@deviant.kiev.zoral.com.ua
On Tue, Jun 29, 2010
On Fri, Aug 06, 2010 at 12:04:04PM +0300, Kostik Belousov wrote:
On Fri, Aug 06, 2010 at 07:06:33AM +0200, Jeremie Le Hen wrote:
Hi Kib,
In-Reply-To: 20100629083901.gg13...@deviant.kiev.zoral.com.ua
On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote:
On Tue, Jun 29, 2010
Hi Kib,
In-Reply-To: 20100629083901.gg13...@deviant.kiev.zoral.com.ua
On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote:
On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote:
On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov wrote:
On Wed, Jun 23, 2010 at
on 11/07/2010 15:23 Andriy Gapon said the following:
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:
On Thu, Jul 15, 2010 at 02:25:26PM +0300, Andriy Gapon wrote:
on 11/07/2010 15:23 Andriy Gapon said the following:
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
on 15/07/2010 14:39 Kostik Belousov said the following:
Is new behaviour completely identical to the behaviour of the newer
ld ?
No, it's not completely identical.
__start_SECNAME placement would be identical, but our ld would still assign the
symbol while latest upstream binutils PROVIDES
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: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/unnecessary
I
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) \
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.new.s
[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:
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 inline
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
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 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 zero-sized
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.
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
allocating section
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 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 Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote:
On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov wrote:
On Wed, Jun 23, 2010 at 11:09:59PM +0200, Jeremie Le Hen wrote:
Hi Kostik,
This patch seems to have faded out from memory. Is it possible to go
forward
On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov wrote:
On Wed, Jun 23, 2010 at 11:09:59PM +0200, Jeremie Le Hen wrote:
Hi Kostik,
This patch seems to have faded out from memory. Is it possible to go
forward and commit it?
I refreshed the patch. Hopefully, nobody will object,
[1] = KERN_ARND;
diff --git a/libexec/rtld-elf/Symbol.map b/libexec/rtld-elf/Symbol.map
index ce1e3e5..f45f955 100644
--- a/libexec/rtld-elf/Symbol.map
+++ b/libexec/rtld-elf/Symbol.map
@@ -24,4 +24,5 @@ FBSDprivate_1.0 {
_rtld_free_tls;
_rtld_atfork_pre;
_rtld_atfork_post
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 module doesn't create any per cpu data of its
--git a/libexec/rtld-elf/Symbol.map b/libexec/rtld-elf/Symbol.map
index ce1e3e5..f45f955 100644
--- a/libexec/rtld-elf/Symbol.map
+++ b/libexec/rtld-elf/Symbol.map
@@ -24,4 +24,5 @@ FBSDprivate_1.0 {
_rtld_free_tls;
_rtld_atfork_pre;
_rtld_atfork_post;
+_rtld_aux_info
the file for writing, locate the .compsign
section and stuff in the signature, write it out and close the file.
(simple ELF manipulation)
An 'ls -l' shows the following:
% ls compklm.ko
-rw-r--r-- 1 pmahan pmahan 125296 Apr 6 22:50 /home/pmahan/temp/compklm.ko
When I try to run my program
(.compsign)));
What I need to do is open the file for writing, locate the .compsign
section and stuff in the signature, write it out and close the file.
(simple ELF manipulation)
An 'ls -l' shows the following:
% ls compklm.ko
-rw-r--r-- 1 pmahan pmahan 125296 Apr 6 22:50
/home/pmahan/temp
[40] __attribute__((section(.compsign)));
What I need to do is open the file for writing, locate the .compsign
section and stuff in the signature, write it out and close the file.
(simple ELF manipulation)
An 'ls -l' shows the following:
% ls compklm.ko
-rw-r--r-- 1 pmahan pmahan 125296
] __attribute__((section(.compsign)));
What I need to do is open the file for writing, locate the .compsign
section and stuff in the signature, write it out and close the file.
(simple ELF manipulation)
An 'ls -l' shows the following:
% ls compklm.ko
-rw-r--r-- 1 pmahan pmahan 125296 Apr 6
Yuri [EMAIL PROTECTED] writes:
Erik Trulsson [EMAIL PROTECTED] writes:
ELF is fairly well documented and standardized.
No, I would say ELF is somewhat documented.
Do not confuse your inability or unwillingness to read a specification
with the absence of such a specification.
http
Yuri wrote:
When I am trying to understand how Elf executable works I am only getting to few
pages with very fragmentary information.
Googling many constants like R_386_PC32, R_386_TLS_LD only yields some
discussion references and code.
Anybody knows where to read more about the Elf format
When I am trying to understand how Elf executable works I am only getting to few
pages with very fragmentary information.
Googling many constants like R_386_PC32, R_386_TLS_LD only yields some
discussion references and code.
Anybody knows where to read more about the Elf format? Does
On Tue, Jan 15, 2008 at 02:46:03PM -0800, Yuri wrote:
When I am trying to understand how Elf executable works I am only getting to
few
pages with very fragmentary information.
Googling many constants like R_386_PC32, R_386_TLS_LD only yields some
discussion references and code.
Anybody
Hi,
On 15 Jan 2008, at 22:46, Yuri wrote:
[...]
Anybody knows where to read more about the Elf format? Does such
document even
exist?
It's originally defined in the System V ABI specification,
http://www.caldera.com/developers/devspecs/gabi41.pdf
--
Bob Bishop +44 (0)118 940
ELF is fairly well documented and standardized.
No, I would say ELF is somewhat documented.
Just googling for 'ELF' quickly yields the Wikipedia page
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
which contains several links to documents describing plenty of details
What specifically you want to know about ELF??
Rayson
On Jan 15, 2008 6:46 PM, Yuri [EMAIL PROTECTED] wrote:
ELF is fairly well documented and standardized.
No, I would say ELF is somewhat documented.
Just googling for 'ELF' quickly yields the Wikipedia page
http://en.wikipedia.org
Yuri wrote:
ELF is fairly well documented and standardized.
No, I would say ELF is somewhat documented.
Just googling for 'ELF' quickly yields the Wikipedia page
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
which contains several links to documents describing plenty
I found *rafal.jaworowski* have wrote some patch to boot freebsd-elf image
through u-boot in freebsd-hackers mail list,
I have a ppc-4xx board ,and want to use u-boot as bootloader,
Can we boot freebsd through u-boot ?
___
freebsd-hackers@freebsd.org
(usr.bin/make), but when I try to execute it I
got the following results:
[EMAIL PROTECTED] ~ # /usr/bin/make
ELF binary type 0 not known.
- -su: /usr/bin/make: cannot execute binary file
[EMAIL PROTECTED] ~ #
I must say that this *only* happends when make is built statically
(if you want it compiled
On Sat, Jul 08, 2006 at 06:08:13AM +0200, Victor Roman Archidona wrote:
at first I should mention that this post is about Gentoo/FreeBSD for
amd64 port, using the Gentoo portage system with FreeBSD sources,
library and so on. If you're not interested in this you can stop
reading now :-).
I'm compiling make (usr.bin/make), but when I try to execute
it I got the following results:
[snip]
'Tis a bug in your toolchain. e_ident[EI_OSABI] in the ELF
header isn't being set correctly for static executables.
--
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy
Hi,
I am one of the firmware guys that is writing a Secondary Boot Loader that
boots FreeBSD kernel. From what I see in the ELF header for FreeBSD kernel, the
load address seems to have a value of 0x8020 which seems to be a Virtual
address for me. If I want to put the Physical
I am one of the firmware guys that is writing a Secondary Boot Loader that
boots
FreeBSD kernel. From what I see in the ELF header for FreeBSD kernel, the load
address seems to have a value of 0x8020 which seems to be a Virtual
address
for me. If I want to put the Physical address
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 asked
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
___
freebsd-hackers@freebsd.org mailing list
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
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
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?
Is it
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 Linux
the error message mention ELF binary type 3, not 0?
So I went ahead and included all the steps, just to cover all bases :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79
the error message mention ELF binary type 3, not 0?
So I went ahead and included all the steps, just to cover all bases :)
I'd be *very* suprised..
I expect he just downloaded an RPM from somewhere..
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
on the executables - if brandelf had been
run, wouldn't the error message mention ELF binary type 3, not 0?
So I went ahead and included all the steps, just to cover all bases :)
I'd be *very* suprised..
I expect he just downloaded an RPM from somewhere..
It's probably just not having linux.ko
/compat/linux/bin/ls
ELF binary type 0 not known.
$ sudo kldload linux.ko
$ kldstat
Id Refs AddressSize Name
15 0xc040 498518 kernel
21 0xc2a1a000 16000linux.ko
$ /usr/compat/linux/bin/ls /bin
basename chgrp cpecho fgrep ls mvrm
AddressSize Name
11 0xc040 498518 kernel
$ /usr/compat/linux/bin/ls
ELF binary type 0 not known.
$ sudo kldload linux.ko
$ kldstat
Id Refs AddressSize Name
15 0xc040 498518 kernel
21 0xc2a1a000 16000linux.ko
$ /usr
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 :)
What I
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 type 3
, 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 elf(5) manpage, and is shown in the
``readelf -h'' output.
You misunderstood me.
My question was why is there a need for a PT_NOTE section (which
Hi,
At the moment, on both OpenBSD and FreeBSD (you're going to have to
excuse my lack of familiarity with NetBSD but I presume this
situation is similar) ELF files are branded via the CSU library,
inside a PT_NOTE section.
I've looked through as much documentation and list archives that I
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 elf
byte following the EI_OSABI byte, which
is both documented in the elf(5) manpage, and is shown in the
``readelf -h'' output.
You misunderstood me.
My question was why is there a need for a PT_NOTE section (which is
a more convaluted way of branding and reading a brand of an elf
binary
: 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 elf(5) manpage, and is shown in the
: ``readelf -h'' output.
:
: You misunderstood me.
:
: My question was why is there a need
php3 and php4 were
both enabled.
I spent long hours reading through commit logs since 4.6.2 and I found a
solution. It turns out that backing out the commits below and replacing
certain ld-elf and libc source files with the appropriate old versions
effectively solves php3+php4 dynamic modules
:It turns out that the kernel's internal ELF loader is misinterpreting
:an ABS symbol (i.e. set with .SET in assembly) whos value is 0 as being
:'not found', and once that is fixed it was also confusing the absolute
:symbol with a COMMON symbol.
:
:Thanks for the pointer. FWIW, We
Matthew Dillon wrote:
I got an odd bug report for DragonFly today. Apparently the module loader
was broken, the kernel complained about not being able to find
'globaldata'.
It turns out that the kernel's internal ELF loader is misinterpreting
an ABS symbol (i.e. set
I got an odd bug report for DragonFly today. Apparently the module loader
was broken, the kernel complained about not being able to find
'globaldata'.
It turns out that the kernel's internal ELF loader is misinterpreting
an ABS symbol (i.e. set with .SET in assembly) whos value
I am trying to write a little program to get some information from core
dump files. I do not understand, however, what is in each of the
loadable segments in the core dump, and how those segments correlate to
the segments in the executable file. For one thing, there are more
loadable segments in
I suggest you read The Design and Implementation of the 4.4BSD Operating System. It
will answer most if not all of your questions.
On Sat, Nov 23, 2002 at 02:05:03AM +0100, [EMAIL PROTECTED] wrote:
OK, I have read some more now and will ask a few questions. If I am asking
the wrong place,
On 2002.11.23 02:13 Jonah Sherman wrote:
I suggest you read The Design and Implementation of the 4.4BSD
Operating System. It will answer most if not all of your
questions.
Funny you should mention that. I ordered that book thursday, It will be
here within 6-8 days :-)
br
socketd
To
OK, I have read some more now and will ask a few questions. If I am asking
the wrong place, please say so.
1. If have found part of what I am looking for:
http://www.cs.ucdavis.edu/~haungs/paper/node14.html#sections
But I need more info (in depth info). Is .bss = the heap?
2. I would like more
is. Btw why
do we need to pad arguments?
3. Why do BSD use the stack and not the registres to pass arguments to functions?
I bet there is a really good reason, but isn't the Linux/Windows way better
performancewise?
4. I would really like to know more (everything) about the ELF file format
On 2002.11.21 17:54 [EMAIL PROTECTED] wrote:
I can't remember if I'm on the list, so please CC to me.
Just found out I'm on the list :-)
br
socketd
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On 2002.11.21 18:00 Bruce M Simpson wrote:
One big question I'd have is, why are you using assembly language?
1. I like assembly
2. FreeBSD will still need assembly programms
3. To learn more about the FreeBSD kernel (internals)
I do however program in C++, so if you are worried about
On 2002.11.21 18:33 Chuck Tuffli wrote:
There is
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86.html
I'm not sure if this is the same as the above link
I'll read it, thanks :-)
br
socketd
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
On 2002.11.21 18:33 Chuck Tuffli wrote:
My questions are:
1. Can you guide my to some good info on asm programming under
FreeBSD (I
have read www.int80h.org/bsdasm)
There is
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86.html
I'm not sure if this is the same
-BEGIN PGP SIGNED MESSAGE-
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.
#define PAGE_SIZE 4096
p_offset % PAGE_SIZE == p_vaddr
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 is done
Can someone take a look at this PR? It seems to still be relevant.
Kris
- Forwarded message from Sergei Laskavy [EMAIL PROTECTED] -
Delivered-To: [EMAIL PROTECTED]
Date: Wed, 31 May 2000 14:03:30 +0400
From: Sergei Laskavy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ELF rlimits
.
This patch is against -current, but I think it will apply cleanly to
-stable too.
Thanks,
John
Index: rtld.c
===
RCS file: /home/ncvs/src/libexec/rtld-elf/rtld.c,v
retrieving revision 1.50
diff -u -r1.50 rtld.c
--- rtld.c 2000/11/07
%===
%RCS file: /home/ncvs/src/libexec/rtld-elf/rtld.c,v
%retrieving revision 1.50
%diff -u -r1.50 rtld.c
%--- rtld.c 2000/11/07 22:41:53 1.50
%+++ rtld.c 2001/01/05 00:13:18
%@@ -77,6 +77,8 @@
% static Obj_Entry *digest_phdr(const
%Could you please try the patch below? It is like the patch that Paul
%sent, except it should handle error conditions better.
%
%This patch is against -current, but I think it will apply cleanly to
%-stable too.
My pleasure. This patch applies cleanly against a two day old
-stable, and
Bingo!
Thanks guys!
Russell
%John Polstra ([EMAIL PROTECTED]) wrote:
% In article [EMAIL PROTECTED],
% Russell L. Carter [EMAIL PROTECTED] wrote:
%
% On a fairly recent -STABLE I am getting this failure:
%
% ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
%
% I
Greetings,
On a fairly recent -STABLE I am getting this failure:
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
I assume I'm doing something stupid, however the same code
works on Linux gcc-2.95.2, so I'm looking for what the
difference might be.
The program is an ACE/TAO
In article [EMAIL PROTECTED],
Russell L. Carter [EMAIL PROTECTED] wrote:
On a fairly recent -STABLE I am getting this failure:
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
I assume I'm doing something stupid, however the same code
works on Linux gcc-2.95.2, so I'm
Umm I should have asked better. I am looking for the ELF Dynamic
Loader, which loads Shared Objects (the thing behind dlopen() et al.).
kern_linker.c looks to me as the loader of kernel objects (.ko files).
On Tue, Dec 19, 2000 at 06:36:00PM -0500, Andrew R. Reiter wrote:
sys/kern
Hello Sven,
Umm I should have asked better. I am looking for the ELF Dynamic
Loader, which loads Shared Objects (the thing behind dlopen() et al.).
kern_linker.c looks to me as the loader of kernel objects (.ko files).
look into /usr/src/libexec/rtld-elf/.
Bjoern
--
-BEGIN GEEK
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 me if
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 friends
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
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]
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 God we
1 - 100 of 189 matches
Mail list logo
