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
o memory at 0x8048000. .text
section is probably part of that, but it's 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 na
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 , I see some thing like this
PIDSTART
e help from somebody having
> > > > > > > access to
> > > > > > > sparc64 system where the problem is reproducable.
> > > > > >
> > > > > > Do you have a debug version of the patch which outputs the necessary
> > > >
uld be
> > > > > > > > nice to have this in the tree.
> > > > > > >
> > > > > > > I cannot move forward without the help from somebody
> > > > > > > having access to sparc64 system where the problem is
> >
necessary
> > > > > information?
> > > >
> > > > I would suggest to build rtld and libc with debugging symbols and
> > > > get full backtrace from the faults.
> > >
> > > v100# gdb /sbin/ifconfig ifconfig.core
> > >
ersion of the patch which outputs the necessary
> > > > information?
> > >
> > > I would suggest to build rtld and libc with debugging symbols and
> > > get full backtrace from the faults.
> >
> > v100# gdb /sbin/ifconfig ifconfig.core
> > GN
gt;
> v100# gdb /sbin/ifconfig ifconfig.core
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show co
uot;show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-marcel-freebsd"...
Core was generated by `ifconfig'.
Program terminated with signal 11, Segmentation fault.
Reading sy
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,
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 T
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,
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
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 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-gen
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:
>> http://people.freebsd.org/~avg/dpcpu/pc
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 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
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
>
error;
if (__stack_chk_guard[0] != 0)
return;
+ if (_rtld_aux_info != NULL)
+ error = _rtld_aux_info(AT_CANARY, __stack_chk_guard,
+ sizeof(__stack_chk_guard));
+ else
+ error = ENOSYS;
+ if (error == 0 && __
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 one
up(void)
> {
> int mib[2];
> size_t len;
> + int error;
>
> if (__stack_chk_guard[0] != 0)
> return;
> + if (_rtld_aux_info != NULL)
> + error = _rtld_aux_info(AT_CANARY, __stack_chk_guard,
> + sizeof(
is stored in each app as
> >
> > unsigned char signature[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.
>
p as
>
> unsigned char signature[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)
>
> A
ction(".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 125
d 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/compk
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
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
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
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
> 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 des
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)11
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 r
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 such
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
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://p
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 :-).
ling "make" (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&q
> 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 t
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
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"
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
bly just not having linux.ko/linprocfs.ko loaded.
> >
> > $ kldstat
> > Id Refs AddressSize Name
> >1 1 0xc040 498518 kernel
> > $ /usr/compat/linux/bin/ls
> > ELF binary type "0" not known.
> >
> > $ sudo kldload linux.ko
>
gt;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 16000li
*not* run brandelf 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 do
un, 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..
--
Daniel O'Connor software and network engineer
for Genesis S
ably 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 error message mention ELF binary type 3, not 0?
So I went ahead and included all the steps,
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
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
http://lists.freebsd.org/mailman/listinfo/f
port 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(5) manpage, and is shown in the
> > ``readelf -h
hen 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(5) manpage, and is shown in the
: > ``readelf -h
'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 is
s both documented in the elf(5) manpage, and is shown in the
``readelf -h'' output.
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
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 archi
ays failed when 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
:>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.
:
:Th
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 misinterpretin
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
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
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 Uns
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,
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 inf
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
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 freebs
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 portabi
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
0% where the return value 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) abou
this adds a -p option to ldconfig so you can do something like:
ldconfig -p /usr/local/lib/libsafe.so
to set a preload, and:
ldconfig -pm /usr/local/lib/libsafe.so
to merge one.
the major problem i know of with this patch is that setting a preload ELF
library will hose your ability to run
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
-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_
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]
> %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
> -stab
hanks,
%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 22:41:53 1.50
%+++ rtld.c 2001/01/05 00:13:18
%@@ -77,
hould handle error conditions better.
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
dif
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 fai
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:
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
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
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
--
-
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:
>
> sy
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]
1 - 100 of 210 matches
Mail list logo
