omain sockets,
accept(2) and shutdown(2). Turns out that the problematic application does both
shutdown(RDWR) and close(2), but that doesn't help on FreeBSD.
BTW, this is the application:
http://thread.gmane.org/gmane.os.freebsd.devel.office/1754
The patch does help.
Author: Andriy Gapon
on 04/04/2013 20:34 Andriy Gapon said the following:
> This seems to work without problems or any warnings with WITNESS &&
> !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the
> relevant code paths.
>
> P.S. Looking through history it seems that in
) at
/usr/src/sys/amd64/amd64/exception.S:387
My understanding is that this happens if sdt.ko is loaded later than some other
dtrace module(s)/providers and there are any (non-sdt) probes active at the time
of loading.
It seems to be caused by sdt_provider_entry() being called on a sdt-based
provider
t
GDT= ff85c789
IDT= 5e00 0197
CR0=0011 CR2= CR3= CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
CCS=0001 CCD= CCO=LOGICL
EFER=0000
on 23/04/2013 19:09 Andriy Gapon said the following:
>
> IN:
> 0x90d2: cli
> 0x90d3: mov$0x1800,%esp
> 0x90d8: mov%cr0,%eax
> 0x90db: and$0x7fff,%eax
> 0x90
on 23/04/2013 19:31 John Baldwin said the following:
> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
>> on 23/04/2013 17:36 Dimitry Andric said the following:
>>> I have tried to ascertain it actually arrives at this code when
>>> rebooting from the load
on 24/04/2013 02:03 Dimitry Andric said the following:
> Indeed, the DS segment was incorrect, the GDT should be loaded from the
> CS segment instead.
Very good catch! Indeed the segments at this point were set up for "user" data
while the "supervisor" data is need
ffloads actual work to
non-interrupt context via a e.g. taskqueue.
But, hmm, this functionality is probably locked under INTR_FILTER option.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-
described earlier.
> -Original Message-
> From: Andriy Gapon [mailto:a...@freebsd.org]
> Sent: Monday, May 27, 2013 10:11 AM
> To: Konstantin Belousov
> Cc: Orit Moskovich; freebsd-hackers@freebsd.org
> Subject: Re: preemptive kernel
>
> on 27/05/2013 09:34 Konstant
ce between them. Is one of the above or
> ithread given to bus_setup_intr preferable on the other?
The differences are described in taskqueue(9) "Predefined Task Queues" section.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailin
K_OVERFLOW
FR_RETIRED_X86_INSTRUCTIONS
FR_RETIRED_UOPS
FR_RETIRED_BRANCHES
FR_RETIRED_BRANCHES_MISPREDICTED
FR_RETIRED_TAKEN_BRANCHES
FR_RETIRED_TAKEN_BRANCHES_MISPREDICTED
--
Andriy Gapon
___
freebsd-hackers@f
on 30/05/2013 18:21 Andriy Gapon said the following:
>
> I am trying to do a very basic thing with hwpmc on this CPU:
>
> CPU: AMD Opteron(tm) Processor 6128 (1999.05-MHz K8-class CPU)
> hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20
> K8/4/48/0x1ff
I didn't realize that the sys
d some ways to feed CPU loading info
> directly in kernel to cpufreq for finer & quicker control of
> frequencies.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ready
copied in. Unlike some fields within select_args.
> arg1 in DTrace script should correspond to uap argument of sys_select, and
> dereferencing should always produce an int.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http:
2 rein kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns),
maxlat=0x00 (0 ns)
Mar 14 19:05:32 rein kernel: intpin=a, irq=16
Mar 14 19:05:32 rein kernel: powerspec 2 supports D0 D3 current D0
Mar 14 19:05:32 rein kernel: MSI supports 1 message, 64 bit
--
Andriy Gapon
___
r me (judging from the lists this is not the
universal case).
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
niel,
maybe you can send a followup to the following ?
http://www.freebsd.org/cgi/query-pr.cgi?pr=110655
Given that 32-bit libthr also doesn't work on 64-bit kernel, the only
option is to map thread libs to libc_r via libmap32.conf.
BTW, next time there is a po
ks like shift is actually done not by specified
number of bits but by that number modulo 64.
Please also mind that the same thing happens if I use a variable instead
of a constant in that expression.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mai
on 03/04/2007 21:02 Stefan Farfeleder said the following:
> On Tue, Apr 03, 2007 at 08:22:15PM +0300, Andriy Gapon wrote:
[...]
>> $ ./test_shl
>>
>>
>> $ uname -srm
>> FreeBSD 6.2-RELEASE-p2 amd64
>> $ gcc -v
>> Usin
y in minority of cases and I am not sure about performance effects (I
do not expect difference in anything else other than performance).
on 01/02/2008 12:27 Andriy Gapon said the following:
> on 01/02/2008 12:00 Andriy Gapon said the following:
>> a different, under-debugged problem
y in minority of cases and I am not sure about performance effects (I
do not expect difference in anything else other than performance).
on 01/02/2008 12:27 Andriy Gapon said the following:
> on 01/02/2008 12:00 Andriy Gapon said the following:
>> a different, under-debugged problem
on 04/02/2008 22:07 Pav Lucistnik said the following:
> Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
>> Andriy Gapon wrote:
>>> More on the problem with reading big directories on UDF.
>> You do realise that you have now made yourself the official
>> mainta
on 04/02/2008 20:36 Julian Elischer said the following:
> Andriy Gapon wrote:
>> More on the problem with reading big directories on UDF.
>
> You do realise that you have now made yourself the official
> maintainer of the UDF file system by submitting a competent
> and insig
on 04/02/2008 17:55 Scott Long said the following:
> Andriy Gapon wrote:
[snip]
>> After some code reading and run-time debugging, here are some facts
>> about udf directory reading:
>> 1. bread-ing is done via device vnode (as opposed to directory vnodes),
>> as a cons
on 05/02/2008 20:16 Pav Lucistnik said the following:
> Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
>
>>> Yay, and can you fix the sequential read performance while you're at it?
>>> Kthx!
>
>> this was almost trivial :-)
>> See the attach
on 05/02/2008 22:43 Scott Long said the following:
> Andriy Gapon wrote:
>
>> But there is another issue that I also mentioned in the email about
>> directory reading. It is UDF_INVALID_BMAP case of udf_bmap_internal,
>> i.e. the case when file data is embedded into a
on 06/02/2008 18:34 Andriy Gapon said the following:
>
> Actually the patch is not entirely correct. max_size returned from
> udf_bmap_internal should be used to calculate number of continuous
> sectors for read-ahead (as opposed to file size in the patch).
>
Attached is an upda
on 06/02/2008 18:29 Andriy Gapon said the following:
> Small summary of the above long description.
> For directory reading fs/udf performs bread() on a (underlying) device
> vnode. It passes block number as if block size was 512 bytes (i.e.
> byte_offset_within_dev/512). On the other
on 06/02/2008 18:29 Andriy Gapon said the following:
> Small summary of the above long description.
> For directory reading fs/udf performs bread() on a (underlying) device
> vnode. It passes block number as if block size was 512 bytes (i.e.
> byte_offset_within_dev/512). On the other
on 12/02/2008 17:58 Bruce Evans said the following:
> On Tue, 12 Feb 2008, Andriy Gapon wrote:
>> And the actual reading works correctly because udf_strategy is called
>> for such vnodes and it translates block numbers from physical to logical
>> and also correctly re-calc
on 12/02/2008 15:11 Bruce Evans said the following:
> On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>>
>>> 2.3. this code passes to bread blkno that is calculated as 4*sector,
>>> where sector
on 12/02/2008 13:47 Poul-Henning Kamp said the following:
> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>
>> 2.3. this code passes to bread blkno that is calculated as 4*sector,
>> where sector is a number of a physical 2048-byte sector. [**]
>> [**] - I th
on 12/02/2008 10:53 Poul-Henning Kamp said the following:
> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>> on 06/02/2008 18:29 Andriy Gapon said the following:
>>> Small summary of the above long description.
>>> For directory reading fs/udf performs
here is a lack of encapsulation: g_vfs_open can make its
own changes in v_bufobj, then filesystem code can modify it further, so
there is no single point of control.
The simplest solution is to disallow this practice altogether.
Another approach that comes to my mind is some kind of vnode "
| OCW2_SL | OCW2_L1);
#endif
Do I understand correctly the code and the comment that here we use a
feature of 8259 PIC that can be called "cyclic shift of interrupt
priorities" ?
So, we really have the following order of interrupts, from higher
priority
Come on, guys, simple yes or no would be enough for me :-)
on 14/02/2008 22:31 Andriy Gapon said the following:
> Dear hackers,
> I'd like to check with you if my understanding of some code is correct.
>
> If we speak about a typical older i386 system, with UP and "AT&q
interrupt ?
I mean, will it be:
... -> iret -> xxx -> xxx -> interrupted again
or
... -> iret -> interrupted again
Is this a deterministic behavior ? Or some timings are at play?
Thank you in advance.
I hope this was not a too trivial o
on 17/02/2008 18:19 Erich Dollansky said the following:
> Hi,
>
> Andriy Gapon wrote:
>
> I cannot tell you if this is still the same for modern designs.
>
>> ... -> iret -> interrupted again
>
> This was the behaviour earlier.
>> Is this a determinis
needing softclock's help?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
system, it competes with IRQ0 and is affected by
scheduler's decisions. Especially those made while in interrupt handler.
on 17/02/2008 17:10 Andriy Gapon said the following:
> on 14/02/2008 23:31 Andriy Gapon said the following:
>> I ran a series of tests, repeating each twice to be sure th
le explanations?
on 19/02/2008 22:09 Andriy Gapon said the following:
> More news about the issue. Finally, I stopped being blind and tried to
> use KTR.
> Graphs produces by schedgraph confirmed my suspicion that system spends
> most if its time in idle thread (sleeping).
>
on 19/02/2008 23:42 Andriy Gapon said the following:
> The last result most probably means that RTC IRQ was not the interrupt
> to wake CPU from sleeping state.
> The first possibility that comes to mind is that on this particular
> hardware RTC interrupt (IRQ8) is not able to wake the
f this is the case, then
the setting must appear under a name and description that I would never
relate to this issue.
Another possible resolution is to check the bits, but instead of
changing them just refuse to use anything lower than C1.
--
Andriy Gapon
___
on 20/02/2008 20:33 Andriy Gapon said the following:
> on 19/02/2008 23:42 Andriy Gapon said the following:
>> The last result most probably means that RTC IRQ was not the interrupt
>> to wake CPU from sleeping state.
>> The first possibility that comes to mind is th
on 22/02/2008 19:00 Torfinn Ingolfsen said the following:
> On Fri, 22 Feb 2008 18:17:27 +0200
> Andriy Gapon <[EMAIL PROTECTED]> wrote:
>
>> Everything works great. But recently I had an itch to go trough BIOS
>> settings. I spotted one named "Plug-n-Play OS&
on 26/02/2008 21:23 Pav Lucistnik said the following:
> Pav Lucistnik píše v út 05. 02. 2008 v 19:16 +0100:
>> Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
>>
>>>> Yay, and can you fix the sequential read performance while you're at it?
>>>> Kthx!
on 28/02/2008 11:59 Pav Lucistnik said the following:
> Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200:
>
> And while I have your attention, I have a related question.
>
> I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with
> mkisofs, and when I mount the UDF
on 06/03/2008 14:55 John Baldwin said the following:
> On Monday 18 February 2008 10:25:13 am Andriy Gapon wrote:
>> I see that sched_4bsd has a NOP callout with a purpose of forcing a
>> context switch (via softclock), so that something like a preemption
>> could happen (
on 27/03/2008 20:08 John Baldwin said the following:
> On Thursday 27 March 2008 12:45:38 pm Andriy Gapon wrote:
>> on 01/03/2008 10:49 Andriy Gapon said the following:
>>> Here's one strange thing - in your patch you accidentally have
>>> parameters of devic
on 28/03/2008 16:37 Andriy Gapon said the following:
> on 27/03/2008 20:08 John Baldwin said the following:
>> On Thursday 27 March 2008 12:45:38 pm Andriy Gapon wrote:
>>> on 01/03/2008 10:49 Andriy Gapon said the following:
>>>> Here's one strange thing -
have to look at the
complete commit message to see what it is about really.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
notifications about hardware/driver events.
But what if I want to automatically run some action if
/dev/ufs/magic-label appears?
Or if I want to monitor appearance and disappearance of ad* and da*
devices (without having to monitor low level drivers like umass)?
--
Andriy Gapon
on 23/04/2008 00:06 Jille said the following:
> Andriy Gapon wrote:
>> Maybe this is a crazy idea or maybe we already have something like this.
>> Is it possible to get notifications about changes in devfs - appearance
>> and disappearance of devices (in devfs sense of
on 23/04/2008 16:55 John Baldwin said the following:
> On Tuesday 22 April 2008 03:54:17 pm Andriy Gapon wrote:
>> Maybe this is a crazy idea or maybe we already have something like this.
>> Is it possible to get notifications about changes in devfs - appearance
>> and disappe
; (attach/detach) events, but I see that "!" (notification) would
be much more appropriate. As you said, this can be completely modeled
after IF notifications.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.
on 24/04/2008 01:39 Andriy Gapon said the following:
> on 23/04/2008 22:49 John Baldwin said the following:
>> Events have a subsystem associated with them, so devfs events would use
>> their
>> own subsystem type to avoid that sort of confusion.
>
> Thank you for
system is booted and devd
is running.
Here is a log of devd started with -dD flags in single-user mode, then I
attached and later detached an external hdd:
http://www.icyb.net.ua/~avg/devd.log.gz
Search for DEVFS for interesting lines.
--
Andriy Gapon
diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs
end) calls itself recursively for child devices, this is all done under
dev_mtx. So I am not sure how to call devctl_notify for those child
devices properly.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listin
nt to stay as
far from computers as possible during it).
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
of May 6.
--
Andriy Gapon
diff --git a/sys/kern/kern_conf.c b/sys/kern/kern_conf.c
index 1db25f8..0245253 100644
--- a/sys/kern/kern_conf.c
+++ b/sys/kern/kern_conf.c
@@ -30,6 +30,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
#include
this?
Thanks.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
0x2 sets bit 1 to 1 (thus selecting hard reset), and
writing 0x6 sets both bits 2 and 1 to 1 (thus performing hard reset).
So we always just do a hard reset, no trying of soft reset (would it
even make sense to do the last line of the comment says).
--
Andriy Gapon
___
on 13/05/2008 22:04 Andriy Gapon said the following:
on 12/05/2008 00:48 Kostik Belousov said the following:
No, we do not have a leak, but we have somewhat non-obvious behaviour.
The cdev structure is freed only after the last reference to cdev is
gone. Typical holder of the reference is the
ntinued on. Apparently this happens because off_t is somewhere
assigned to caddr_t (or something like that) without any extra checks.
So, I am curious if this intentional, unintentional or it just happened
to be this way and nobody really cares.
--
An
about the names I picked
3. I slightly don't like a fact that parent-child destroy notifications
are sent in reverse order because of my simplistic LIST usage.
--
Andriy Gapon
diff --git a/sys/kern/kern_conf.c b/sys/kern/kern_conf.c
index 1db25f8..0245253 100644
--- a/sys/kern/kern_conf.c
+++
p;devmtx);
Thank you again! This is simply perfect.
--
Andriy Gapon
diff --git a/sys/kern/kern_conf.c b/sys/kern/kern_conf.c
index 1db25f8..f90e469 100644
--- a/sys/kern/kern_conf.c
+++ b/sys/kern/kern_conf.c
@@ -30,6 +30,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
on 14/05/2008 15:19 Kostik Belousov said the following:
> On Tue, May 13, 2008 at 11:40:21PM +0300, Andriy Gapon wrote:
>> on 13/05/2008 22:16 Kostik Belousov said the following:
>>> I looked at your previous patch, and it seems it is much simpler to
>>> do drop the devm
updates with cvsup.
Then do fromcvs incremental import into "pristine" GIT repository.
And then do 'git pull' into the working GIT repo.
Hope that this will be interesting and/or useful to the community.
--
Andriy Gapon
___
freebsd-hackers@fr
Does i386 FreeBSD depend for anything important on "traditional" BIOS or
will it be able to load and work without it?
I mean with something like coreboot.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.o
case.
Something like create /dev/cpuN and allow some ioctls on it:
ioctl(cpu_fd, CPU_RDMSR, arg).
What do you think?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
on 17/05/2008 13:12 Kostik Belousov said the following:
On Sat, May 17, 2008 at 11:13:52AM +0300, Andriy Gapon wrote:
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted from userland. Maybe we should
provide something like Linux /dev
on 17/05/2008 18:37 Rui Paulo said the following:
Andriy Gapon wrote:
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted from userland. Maybe we
should provide something like Linux /dev/cpu/msr?
I don't like interface of that d
n not
understand an approach of limiting abilities of a (sufficiently)
privileged user. After all, he/she can rebuild a kernel and put all they
need into it.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mail
rce code I immediately noticed the bp
condition in vdev_read_phys and realized what the problem was.
Hope this would be a useful reading.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Do you have such a shim that you could share?
I'd be much obliged for it. And not only I, I think.
Thanks!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
on 28/05/2010 17:49 Doug Rabson said the following:
>
>
> On 27 May 2010 16:13, Andriy Gapon <mailto:a...@icyb.net.ua>> wrote:
>
> on 27/05/2010 17:40 Doug Rabson said the following:
> >
> > Excellent work - thanks for looking into this. I sti
> wont do the trick. I need the children to have their own private mount
> namespaces.
I am afraid that FreeBSD doesn't have this capability.
There is a single mount namespace per whole system image.
BTW, I am intrigued, in what situations this
_load_file in all places that need to
map loaded module's sections to load addresses?
What do you think?
Thanks!
P.S.
As I understand CTF data includes a symbol table.
What kind of symbol addresses is used there? Are they relative within a
corresponding section? Or something else?
-
t section addresses in amd64 .ko (relocatable object file)
similarly to how they are set in i386 .ko (full-blown DSO)?
Or is this too much useless hassle?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mai
on 21/06/2010 23:44 Navdeep Parhar said the following:
> On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote:
>> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
>>> on 21/06/2010 18:43 John Baldwin said the following:
>>>> np@ has a patch to gdb to
ight?
It's definitely pointless.
[IMHO :-)]
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
on 22/06/2010 00:34 Andriy Gapon said the following:
> gdb change - I'd rather do it via kld_current_sos,
> kld_relocate_section_addresses. I'd like to avoid changing common gdb code
> for
> a variety of reasons.
I came up with the following patch.
EXEC_P and DYNAMIC
: U __start_set_sysctl_set
> ./cuse4bsd.ko:28cc A __start_set_sysinit_set
> ./cuse4bsd.ko:28c8 A __start_set_sysuninit_set
> ./cuse4bsd.ko: U __stop_set_sysctl_set
> ./cuse4bsd.ko:28d0 A __stop_set_sysinit_set
> ./cuse4bsd.ko:28cc A __stop_set_sysuninit_set
on 23/06/2010 09:52 Hans Petter Selasky said the following:
> On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
>> on 23/06/2010 03:38 Hans Petter Selasky said the following:
>>> Hi,
>>>
>>> I'm creating a new thread on this issue.
>>>
>&g
on 23/06/2010 10:02 Andriy Gapon said the following:
> I don't dispute that it is found broken in particular environments, I just
> think
> that the analysis could be incorrect.
Which also brings the question - what arch(s) is affected?
I tested on amd64.
--
on 23/06/2010 18:03 Ryan Stone said the following:
> On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote:
>> Which also brings the question - what arch(s) is affected?
>> I tested on amd64.
>
> This should explain it. It looks to me like i386 uses kern/link_elf.c
> as
case SHT_PROGBITS:
case SHT_NOBITS:
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
duced by GNU ld
+* for ELF objects and libraries:
+* [Text][R/O data][R/W data][Dynamic][BSS][Non loadable]
+*/
+ dmp->dm_text_size = dmp->dm_data_va - dmp->dm_text_va;
#if defined(__i386__)
/*
* Find the first load section and figure out the relocation
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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
>> copie
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 p
8
.globl pcpu_entry_dpcpu_nvram2
.align 8
.type pcpu_entry_dpcpu_nvram2, @object
.size pcpu_entry_dpcpu_nvram2, 8
pcpu_entry_dpcpu_nvram2:
.zero 8
.data
...
Here's objdump of the resulting module:
objdump -x -w nvram.ko | fgrep set_pc
on't we want that data to be considered writable? Haven't we just said that we
want "aw"? Don't we explicitly create a section with "aw" flags?
And why do we need a (universal) initializer? Why is it mentioned here at all?
Educate me. I demand it! :
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
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
[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
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 completen
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
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://pe
tream binutils PROVIDES it.
> Even if yes, I think that such changes make potential import of
> newer binutils harder.
How?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubs
e code or are the comments
outdated/misleading/not-descriptive-enough?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
301 - 400 of 614 matches
Mail list logo
