Hi folks,
We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
Does anyone feel up to writing one?
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom
finally thinking of doing the
> > > > 2.2.8-STABLE to 3.2-STABLE upgrade.
> > > >
> > > > I have upgraded within a major release several times (a number of
> > > > 2.2.7 to 2.2.8 and 3.1 to 3.2 systems), but never done the a.out to
> > > >
On Mon, Aug 30, 1999 at 09:13:58AM -0700, Doug wrote:
> I've seen quite a few reports of this lately, and while this fixes it, it
> shouldn't be necessary, should it? Has something changed in the 'make
> upgrade' target recently?
`make' has changed.
--
John Birrell - [EMAIL PROTECTED]; [
On Tue, 31 Aug 1999, John Birrell wrote:
> On Mon, Aug 30, 1999 at 09:13:58AM -0700, Doug wrote:
> > I've seen quite a few reports of this lately, and while this fixes it, it
> > shouldn't be necessary, should it? Has something changed in the 'make
> > upgrade' target recently?
>
> `make' h
On Mon, Aug 30, 1999 at 03:55:42PM -0700, Doug wrote:
> > `make' has changed.
>
> Ok, that's the cause then, so what's the solution? :) And
> meanwhile is it going to hurt anything if I put a suggestion on my 'make
> upgrade' web page that users do 'make -DMACHINE_ARCH=i386 upgrade' as a
>
John Birrell wrote:
>
> On Mon, Aug 30, 1999 at 03:55:42PM -0700, Doug wrote:
> > > `make' has changed.
> >
> > Ok, that's the cause then, so what's the solution? :) And
> > meanwhile is it going to hurt anything if I put a suggestion on my 'make
> > upgrade' web page that users do 'make -D
est the patch because
you won't execute the code in question. Do I really need to send you
a patch to change one word in /usr/src/usr.bin/make/main.c?! Please take
a few moments to have a look for "unknown" in that file. Sigh.
If there is someone with a scratch disk on which they ca
On Wed, 1 Sep 1999, John Birrell wrote:
> If there is someone with a scratch disk on which they can install 2.2.8
> (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results,
> we could get this sorted out. I don't have the hardware to do that
> anymore. An
On Wed, 1 Sep 1999, John Birrell wrote:
> On Tue, Aug 31, 1999 at 08:27:00AM -0700, Doug wrote:
> > John Birrell wrote:
> > > The solution is to fix `make'. I could commit the fix, but I'm not
> > > in a position to build -stable just now. I'm not supposed to commit
> > > without testing. The fix
> If there is someone with a scratch disk on which they can install 2.2.8
> (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results,
> we could get this sorted out. I don't have the hardware to do that
> anymore. Any list-lurkers want to help out?
The obvious one-lin
On Tue, Aug 31, 1999 at 10:12:27PM -0500, David Scheidt wrote:
> The obvious one-line fix appears to work. My 2.2.6 to RELENG_3 build hasn't
> finished yet, but it makes it past the point where it fails due to
> machine_arch be ing undefined. Do I need to check if 2.2.6 to -CURRENT
> works?
I
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
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
--
-
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
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
:>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
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
* Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> Hi folks,
>
> We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
>
> Does anyone feel up to writing one?
Saw it before, noticed it, placed on my to-do list. If no-one objects
I'll submit a
On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
> If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> for review untill it's ready for inclusion.
Anyone who objects to your submissions is a woes -- real bastards wait
for you to do the work before shooting you
* Sheldon Hearn (sheld...@uunet.co.za) [990801 00:35]:
>
>
> On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
>
> > If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> > for review untill it's ready for inclusion.
>
> Anyone who objects to your submissions is
Jeroen Ruigrok/Asmodai wrote:
>
> * Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> > Hi folks,
> >
> > We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> >
> > Does anyone feel up to writing one?
>
> Saw it before,
* Wes Peters (w...@softweyr.com) [990801 07:12]:
> Jeroen Ruigrok/Asmodai wrote:
> >
> > * Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> > >
> > > We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> > >
> > >
Sheldon Hearn wrote:
>
> On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
>
> > If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> > for review untill it's ready for inclusion.
>
> Anyone who objects to your submissions is a woes -- real bastards wait
> for yo
Wes Peters writes:
> NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
It'd be cool if Asmodai could bounce this around one of the NetBSD lists
once it's near completion. tech-toolchain@ or tech-userlevel@ would be the
right place I guess.
- ad
To Unsubscribe: send ma
* Andy Doran (a...@netbsd.org) [990802 00:53]:
> Wes Peters writes:
>
> > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
>
> It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> once it's near completion. tech-toolchain@ or tech-userlevel@ would b
Jeroen Ruigrok/Asmodai wrote:
>
> * Andy Doran (a...@netbsd.org) [990802 00:53]:
> > Wes Peters writes:
> >
> > > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
> >
> > It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> > once it's near completio
* Wes Peters (w...@softweyr.com) [990803 10:13]:
> Jeroen Ruigrok/Asmodai wrote:
> > * Andy Doran (a...@netbsd.org) [990802 00:53]:
> > > Wes Peters writes:
> > > > NetBSD doesn't have one as of 1.4, so they may be interested in yours.
> > > > ;^)
> > >
> > > It'd be cool if Asmodai could bounce
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
* Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> Hi folks,
>
> We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
>
> Does anyone feel up to writing one?
Saw it before, noticed it, placed on my to-do list. If no-one objects
I'll submit a manpage per a.o
On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
> If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> for review untill it's ready for inclusion.
Anyone who objects to your submissions is a woes -- real bastards wait
for you to do the work before shooting yo
* Sheldon Hearn ([EMAIL PROTECTED]) [990801 00:35]:
>
>
> On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
>
> > If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> > for review untill it's ready for inclusion.
>
> Anyone who objects to your submissions is a
Jeroen Ruigrok/Asmodai wrote:
>
> * Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> > Hi folks,
> >
> > We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> >
> > Does anyone feel up to writing one?
>
> Saw it before, noticed it,
* Wes Peters ([EMAIL PROTECTED]) [990801 07:12]:
> Jeroen Ruigrok/Asmodai wrote:
> >
> > * Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> > >
> > > We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> > >
> > > Does anyone feel
Sheldon Hearn wrote:
>
> On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
>
> > If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> > for review untill it's ready for inclusion.
>
> Anyone who objects to your submissions is a woes -- real bastards wait
> for y
Wes Peters writes:
> NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
It'd be cool if Asmodai could bounce this around one of the NetBSD lists
once it's near completion. tech-toolchain@ or tech-userlevel@ would be the
right place I guess.
- ad
To Unsubscribe: send m
* Andy Doran ([EMAIL PROTECTED]) [990802 00:53]:
> Wes Peters writes:
>
> > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
>
> It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> once it's near completion. tech-toolchain@ or tech-userlevel@ woul
Jeroen Ruigrok/Asmodai wrote:
>
> * Andy Doran ([EMAIL PROTECTED]) [990802 00:53]:
> > Wes Peters writes:
> >
> > > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
> >
> > It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> > once it's near comple
* Wes Peters ([EMAIL PROTECTED]) [990803 10:13]:
> Jeroen Ruigrok/Asmodai wrote:
> > * Andy Doran ([EMAIL PROTECTED]) [990802 00:53]:
> > > Wes Peters writes:
> > > > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
> > >
> > > It'd be cool if Asmodai could bounce this a
. make LANGUAGES=c
and I get
--- snip ---
./xgcc -B./ -DIN_GCC -g -I./include enquire.o -o enquire
/usr/libexec/elf/ld: cannot open crt0.o: No such file or directory
*** Error code 1
Stop.
--- snip ---
I presume that this is an a.out vs elf issue -- gcc is trying to build an
a.out version and
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://p
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.
Everything seems to be working. But I am stuck with an ELF executable
file stored in this
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 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 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 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 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.
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__
-
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
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.n
[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 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
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/unnecess
-o enquire
/usr/libexec/elf/ld: cannot open crt0.o: No such file or directory
*** Error code 1
Stop.
--- snip ---
I presume that this is an a.out vs elf issue -- gcc is trying to build an
a.out version and 3.3-R is elf. However, I get the same problem if I try
configure with "configure
>
> 1. configure
> 2. remove references to gnumalloc in Makefile and cp/Makefile
> 3. make LANGUAGES=c
>
> and I get
>
> --- snip ---
> ./xgcc -B./ -DIN_GCC -g -I./include enquire.o -o enquire
> /usr/libexec/elf/ld: cannot open crt0.o: No such file or di
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
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
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
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
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
odify the mmap() so that this
works. But this mmap() is done by the user, I can intercept it at the
mmap() system call. As I said in my original email, the kernel uses
memory map internally to load an ELF object file. I have to let the kernel
know that there is a disk inode at the beginning of
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 b
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
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, 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
sfers and potentially extra seeking.
:
:Yes. The cp command may use mmap(). I modify the mmap() so that this
:works. But this mmap() is done by the user, I can intercept it at the
:mmap() system call. As I said in my original email, the kernel uses
:memory map internally to load an ELF object f
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.
>
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
> 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
>
> > 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,
>
In message <[EMAIL PROTECTED]> Marcin Cieslak
writes:
: Once can easily read them with low-level pccardc interface.
: In general, flash cards are not meant to be written too often,
: so I belive we won't put a real filesystem on them.
: Just a kernel and mfsroot image perhaps?
Well, there is mfs
Marcin Cieslak wrote:
>
> On Wed, 12 Jan 2000, Warner Losh wrote:
>
> > The linear flash cards don't have an ata interface,
> > so PAO and soon -current won't recognize them.
>
> They don't have and we don't need it.
> Once can easily read them with low-level pccardc interface.
> In general, fl
In message <[EMAIL PROTECTED]> Wes Peters writes:
: Modern flash chips support on the order of 1,000,000 write cycles, so this
: is not such a concern anymore. There is no reason why we shouldn't put
: a filesystem on a flash card.
We weren't talking about modern flash cards :-). These flash ca
On Wed, 12 Jan 2000, Warner Losh wrote:
> The linear flash cards don't have an ata interface,
> so PAO and soon -current won't recognize them.
They don't have and we don't need it.
Once can easily read them with low-level pccardc interface.
In general, flash cards are not meant to be written too
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 t
the details behind the scene.
I notice that gensetdefs looks for the sections by the `.set.'-prefixed
name in all the ELF kernel object files, and produces the setdef[12].c
accordingly. Does the `.set.'-prefixed section name have any special
meaning in an ELF object file? I hope someone can
the details behind the scene.
I notice that gensetdefs looks for the sections by the `.set.'-prefixed
name in all the ELF kernel object files, and produces the setdef[12].c
accordingly. Does the `.set.'-prefixed section name have any special
meaning in an ELF object file? I hope someone can
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
many object files. The
first word contains the number of elements (pointers) in the set.
Then come the pointers themselves. Finally, a NULL pointer appears
at the end of the set.
The old a.out linker supported linker sets directly, and did all the
bookkeeping necessary to keep track of the set sizes and
from many object files. The
first word contains the number of elements (pointers) in the set.
Then come the pointers themselves. Finally, a NULL pointer appears
at the end of the set.
The old a.out linker supported linker sets directly, and did all the
bookkeeping necessary to keep track of the set s
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
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:
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
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
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,
> %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
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
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(
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 && __
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
>
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 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
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 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,
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
101 - 200 of 210 matches
Mail list logo
