* [Bug 6303] Fujitsu-Siemens P4 Amilo D 7830 laptop has no govenors with 2.6.16
From: bugme-daemon @ 2006-04-08 23:19 UTC (permalink / raw)
To: cpufreq
http://bugzilla.kernel.org/show_bug.cgi?id=6303
------- Additional Comments From cbradney@zip.com.au 2006-04-08 16:19 -------
Seems to be back with 2.6.17rc1, although the minimum Mhz is now around 2333
even with powersave governor active, max is 2666.600 (correct). The minimum
with 2.6.15 and before used to be 333.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply
* Re: 2.4.32: unresolved symbol unregister_qdisc
From: George P Nychis @ 2006-04-08 23:18 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20060408.155430.111013393.davem@davemloft.net>
Yeah, this module is unfortunately not under the GPL, it was made for research and i am not the author, I was only given the code for my own research.
I enabled that support in the kernel, and then tried to recompile and get tons of errors/warnings... so maybe I am missing something else to be enabled in the kernel... here are a few examples of errors:
/usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or directory
/usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or directory
/usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here (not in a function)
/usr/include/asm/hw_irq.h:28: error: `NR_IRQ_VECTORS' undeclared here (not in a function)
I think those are the top most errors, so if i can fix those hopefully the rest shall vanish!
- George
> From: "George P Nychis" <gnychis@cmu.edu> Date: Sat, 8 Apr 2006 18:47:34
> -0400 (EDT)
>
>> Hey,
>>
>> I have a kernel module that uses unregister_qdisc and register_qdisc,
>> whenever i try to insert the module I get:
>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
>> unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
>> register_qdisc
>>
>> Am i missing some sort of support in the kernel?
>
> Make sure CONFIG_NET_SCHED is enabled and that you compiled your module
> against that kernel.
>
> Where does this sch_xcp come from? It's not in the vanilla sources.
>
> Also, please direct networking questions to the netdev@vger.kernel.org
> mailing list which I have added to the CC:.
>
>
--
^ permalink raw reply
* Re: [linux-lvm] LVM over IP network
From: Sander Steffann @ 2006-04-08 23:19 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <1144412972.44365b2c36361@mail.sify.com>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
Hi,
I have 10 Dell workstation on a LAN. Each workstation has 80
GB hard drive. Two workstations consumed most of the disk space and
remaining eight workstations still has plenty of disk space unused.
...
What I want basically, if I could just collect those 800 GB
excess space (not utilized) and assign it to the work stations starving
for disk space. Is this achievable through LVM or EVMS?
I would never do something like this. You make each workstation dependent on all the other workstations. If one of them is turned off, crashes, dies, etc. your other workstations lose their data. Disks are cheap these days. Just buy an extra drive for the workstations that need it.
Good luck,
Sander
[-- Attachment #2: Type: text/html, Size: 1564 bytes --]
^ permalink raw reply
* Re: How to create independent branches
From: colin @ 2006-04-08 23:15 UTC (permalink / raw)
To: peter.baumann; +Cc: git
669 git-symbolic-ref HEAD refs/heads/slave
670 echo "ref: refs/heads/master" > .git/HEAD
671 git-symbolic-ref HEAD refs/heads/slave
672 git add bar
> Another question. I'd like to create a totaly independent branch (like
> the "todo" branch in git). Is there a more user friendly way than doing
>
> git-checkout -b todo
> rm .git/refs/heads/todo
> rm .git/index
> rm <all_files_in_your_workdir>
>
> ... hack hack hack ...
> git-commit -a
>
> I looked all over the docs, but can't find anything obvious.
If I undertstand, you basically want to create a second
initial commit, so you have two trees in your repository.
Well, an initial commit is just a commit object with no parents.
Try:
- Set up the workdir the way you want. You have to git-add
any newly added files, but git-update-index (called by
git-commit -a) will remove from the index any files
removed from the working directory, so you don't have to
worry about those.
- Make sure refs/heads/todo doesn't exist
- "git-symbolic-ref HEAD refs/heads/todo"
This makes HEAD a symlink (well, symref) to refs/heads/todo,
which doesn't exist.
- git-commit -a
Since the HEAD link doesn't exist, this does an initial
commit.
It's not supremely user friendly, because multiple initial commits can
lead to problems down the road trying to merge, so you'd better know what
you're doing.
Another option is to just set up a second working directory, with a
shared object store, and do the checkin from there. You can have the
.git/refs directories shared (via a symlink) or not. If they're not
shared, you can later make them shared by copying over the relevant refs.
Oh, yes, note that if you fat-finger the "git-symbolic-ref HEAD" command,
any attempts to fix it will complain "not a git repository".
That's because a reference to refs/heads/ in HEAD is how git
identifies a repository. "echo ref: refs/heads/master > .git/HEAD"
will fix it.
^ permalink raw reply
* Re: Accessing physical memory
From: Arnd Bergmann @ 2006-04-08 23:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200604082352.55490.antonio.dibacco@aruba.it>
On Saturday 08 April 2006 23:52, Antonio Di Bacco wrote:
> How can I access the physical memory? Can I MMAP for example /dev/mem? Is
> there a simpler way?
/dev/mem access is the most simple way. A cleaner solution is usually to
write your own simple character device driver for the stuff you want to
access in memory.
Depending on why you want to access memory, slram may be the right
driver, e.g. when you want to store a file system there.
Arnd <><
^ permalink raw reply
* Re: 2.4.32: unresolved symbol unregister_qdisc
From: David S. Miller @ 2006-04-08 22:54 UTC (permalink / raw)
To: gnychis; +Cc: linux-kernel, netdev
In-Reply-To: <32947.128.2.140.234.1144536454.squirrel@128.2.140.234>
From: "George P Nychis" <gnychis@cmu.edu>
Date: Sat, 8 Apr 2006 18:47:34 -0400 (EDT)
> Hey,
>
> I have a kernel module that uses unregister_qdisc and register_qdisc, whenever i try to insert the module I get:
> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol unregister_qdisc
> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol register_qdisc
>
> Am i missing some sort of support in the kernel?
Make sure CONFIG_NET_SCHED is enabled and that you compiled your module against
that kernel.
Where does this sch_xcp come from? It's not in the vanilla sources.
Also, please direct networking questions to the netdev@vger.kernel.org
mailing list which I have added to the CC:.
^ permalink raw reply
* Re: Userland swsusp failure (mm-related)
From: Rafael J. Wysocki @ 2006-04-08 22:47 UTC (permalink / raw)
To: Pavel Machek; +Cc: Fabio Comolli, linux-kernel, Nick Piggin
In-Reply-To: <20060408161555.GA1722@elf.ucw.cz>
Hi,
On Saturday 08 April 2006 18:15, Pavel Machek wrote:
> > > This is my first (and unique) failure since I began testing uswsusp
> > > (2.6.17-rc1 version). It happened (I think) because more than 50% of
> > > physical memory was occupied at suspend time (about 550 megs out og
> > > 1G) and that was what I was trying to test. After freeing some memory
> > > suspend worked (there was no need to reboot).
> >
> > Well, it looks like we didn't free enough RAM for suspend in this case.
> > Unfortunately we were below the min watermark for ZONE_NORMAL and
> > we tried to allocate with GFP_ATOMIC (Nick, shouldn't we fall back to
> > ZONE_DMA in this case?).
> >
> > I think we can safely ignore the watermarks in swsusp, so probably
> > we can set PF_MEMALLOC for the current task temporarily and reset
> > it when we have allocated memory. Pavel, what do you think?
>
> Seems little hacky but okay to me.
>
> Should not fixing "how much to free" computation to free a bit more be
> enough to handle this?
Yes, but in that case we'll leave some memory unused. ;-)
Rafael
^ permalink raw reply
* [Qemu-devel] [usb] correct position of hid descriptor for emulated usb mouse
From: Lonnie Mendez @ 2006-04-08 22:47 UTC (permalink / raw)
To: qemu-devel
I was trying out qemu's emulated usb mouse under debian sid and
windows xp. It worked fine under debian but failed to start under
windows xp guest.
It turns out the hid descriptor in the qemu_mouse_config_descriptor
array is out of position. Please see section 7.1 in the document HID1_11:
"The HID descriptor shall be interleaved between the Interface and
Endpoint descriptors for HID Interfaces. That is, the order shall be:
Configuration descriptor
Interface descriptor (specifying HID Class)
HID descriptor (associated with above Interface)
Endpoint descriptor (for HID Interrupt In Endpoint)
Optional Endpoint descriptor (for HID Interrupt Out Endpoint)"
The patch is linked below:
http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
^ permalink raw reply
* 2.4.32: unresolved symbol unregister_qdisc
From: George P Nychis @ 2006-04-08 22:47 UTC (permalink / raw)
To: linux-kernel
Hey,
I have a kernel module that uses unregister_qdisc and register_qdisc, whenever i try to insert the module I get:
/lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol unregister_qdisc
/lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol register_qdisc
Am i missing some sort of support in the kernel?
Please CC all responses directly to me :)
Thanks!
George
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: linux @ 2006-04-08 22:45 UTC (permalink / raw)
To: linux-kernel; +Cc: hancockr, James
> I wouldn't think most BIOSes these days would bother to clear system RAM
> on a reboot. Certainly Microsoft was encouraging vendors not to do this
> because it slowed down system boot time.
I don't think they explicitly clear it all, but they do write to it to
test how much RAM is installed and don't bother to put back what they
scribbled on.
Sufficient ECC techniques sould probably recover from the damage. For a
first attempt, I'd take 4096-byte pages, not use the first and last 8
bytes at all, and divide the remaining 4080 bytes into 16 interleaved
255-byte ECC segments, each using a byte-wide Reed-Solomon code.
(The fraction of that 255 devoted to ECC is up to you; n-bit-wide
Reed-Solomon just requires that data + ECC <= (2^n - 1) bytes of n
bits each.)
For extra hack value, you could detect at boot what parts of your
log got corrupted and avoid using those parts when logging new data.
(There are complications...)
It is possible to update RS ECC incrementally, or perhaps it would be
better to store the tail of the log in some less efficient form (like
multiple replication) and then pack it into ECC when full.
The other thing that might be a problem is that I don't know how long
refresh stops during reset. Again, ECC can be your friend.
(And code for it already exists in lib/reed_solomon/)
^ permalink raw reply
* Re: Raid 4 idea!
From: JaniD++ @ 2006-04-08 22:40 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-raid
In-Reply-To: <443824A8.6070903@tmr.com>
Hello,
...
> > What do you think, Neil?
> I don't know what Neil thinks, but I have never liked the performance
implications of RAID-4, could you say a few words about why 4 rather than
5? My one test with RAID-4 showed the parity drive as a huge bottleneck, and
seeing that practice followed theory, I gave up on it.
I think the performance is depend on the specific job.
In my case, the level 4 is better than level 5.
My system is a download server.
This job makes a lot of reads, and some write.
I use 4x12 unit raid4 array, and 1 raid0 array from 4 raid4.
Why?
let me see:
1. easy to start without the parity disk.
1/a without the parity disk, it is more faster than raid5/4, and i can
easy and fast upload the server with data, and after the upload is done,
relatively quickly can generate the 4x1 parity information at one time!
1/b if more disk fails, a little easyer to recover than raid5
2. I speaks more read and a little write.
On raid5 if somebody want to write only one bit to the array, all drive need
to read, and two disk is need to write after.
This requires too much time to force to wait the read processes.
But on raid4, all the drives need to read, and only one of the valuable
drives need to write! (+ the parity drive)
This is a little bit faster for me...
3. and this is the most important:
My system have 2 bottleneck with about 1000 downloader users at one time:
a, the drives seek time
b, the io bandwith.
I can make the balance between this 2 bottleneck with the readahead
settings.
On raid 5 the blockdev readahead _reads the parity too_, and waste the
bandwith, and the cache of the drive, the cache in memory, but can seeks N
drive.
On raid 4, the readahead is all valuable, but i can use only N-1 drive to
seeking.
4. on case of very high download traffic, and requires an upload too, i can
disable the party, and speed up the write process, and after the load is
fall back to normal, i can recreate the parity again.
This is a balance between the performance, and redundancy.
This is a little dangerous, but this is my choise, and this way is, why
linux is so beautiful! :-)
5. with Neils patch i can use the bitmap too. ;-)
6. the parity drive becomes the bottleneck because it is offload the other
drives.
On other hand, if i plan to upgrade the system, i only need to buy faster
parity device! :-)
7/a on extreme case, i can move the parity out from the box, using NBD.
The nbd server can speed up and / or can store all the four parity drive
with more cost effective way.
7/b Optionally i can set up the NBD server again, and silenty (slowly)
reconstruct the parity again using the legacy raid 1, and i can use one USB
mobile rack to move the live parity from loop device to the new HDD in rack,
and i need to stop the system only for replace the bad disk to the new done
synced parity drive.
(I did not use hot-swap at the moment.)
> And in return I'll point out that this makes recovery very expensive, read
everything while reconstructing, then read everything all over again when
making a new parity drive after repair.
On my idea?
Yes, this is right.
But!
If one drive is failing, the parity disk convertion close equal time to
reconstruction, except, it goes more and more faster while the degraded
raid4 array gets closer to the clean raid0! (raid4 without parity)
And with one (exactly 4x1) failed drive my system can go on the top
performance, until i replace the old drive to new one.
The final parity recreation on raid4:
I can only point to the mdadm default raid5 creation mechanism, the "fantom"
spare drive!
Neil sad, this is faster than norma raid5 creation, and he have right!
With this option, only 1 disk is writing, and all other is only reading!
Cheers,
Janos
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply
* Xen cpufreq support status: how to notify hypervisor of frequency change?
From: Matt T. Yourst @ 2006-04-08 22:29 UTC (permalink / raw)
To: xen-devel; +Cc: yourst
Hi,
I previously posted a patch to make the dom0 cpufreq drivers properly use
DOM0_MSR (instead of wrmsr) to adjust the processor frequency and voltage.
This does indeed adjust the frequency, but Xen seems to have major latency
problems whenever the frequency change takes affect, causing various problems
like losing mouse events, uncontrolled keyboard repeats, and choppy audio and
video playback for a few seconds after the shift.
This appears to happen because virtual timer interrupts do not get delivered
on a regular basis for a few seconds following the frequency change.
Assuming we want to keep the cpufreq driver itself in dom0, what's the proper
way to notify the hypervisor that the CPU frequency has just changed, so it
can adjust its timers like the cpufreq driver on the native kernel does?
I'd really like to have cpufreq working properly under Xen (for both
workstations and to a lesser extent servers), so what would be the best way
to get this running?
- Matt Yourst
-------------------------------------------------------
Matt T. Yourst yourst@cs.binghamton.edu
Binghamton University, Department of Computer Science
-------------------------------------------------------
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: JustFillBug @ 2006-04-08 22:28 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <4437E4B7.40208@superbug.co.uk>
On 2006-04-08, James Courtier-Dutton <James@superbug.co.uk> wrote:
> Andi Kleen wrote:
>> Reset button is like a cold boot and it generally ends up with cleared
>> RAM.
>>
> Thank you. That saved me 30mins hacking. :-)
>
How about Magic sysRq reboot?
^ permalink raw reply
* [parisc-linux] Q: TLS local dynamic case and zero initialized ti_offset?
From: Carlos O'Donell @ 2006-04-08 22:16 UTC (permalink / raw)
To: Randolph Chung, parisc-linux
Randolph,
In the local dynamic case we emit one reloc R_PARISC_TLS_DTPMOD32.
This means that at runtime there is a GOT entry with an absoluate
address which points to a tls_index structure, which has it's
ti_module filled by the dynamic loader (after processing the DTPMOD32
reloc). The question I have is, does this tls_index appear in bss? Is
the offset ti_offset initialized to zero? The zero offset is required
since we want __tls_get_addr to return the start of the modules block,
so we can subsequently offset into that block without calling
__tls_get_addr again.
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* [linux-lvm] Concise LVM Summary
From: linux_user98765 @ 2006-04-08 21:11 UTC (permalink / raw)
To: linux-lvm
I'm trying to write a perl script to give concise output of
pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay and df -- something
like:
VG home [PE (4MB): 0 (0 b) / 52205 (203.93 GB)]
LV /dev/home/lvol0 /home [LE: 52205 (203.93 GB); DF: 64G/201G (129G)
34%]
PV /dev/sdb [PE (4096KB): 0 (0 b) / 38156 (149.05 GB); DF: ??/149G (??)
??%]
PV /dev/hdb4 [PE (4096KB): 0 (0 b) / 14049 (54.88 GB); DF: ??/55G (??)
??%]
however, there are a few things I have yet to figure out:
- determine the actual disk usage of a particular PV in a given LV
- the lvs column option which produces the heading "Log"
- the nature of the pvs,vgs,lvs separator inconsistencies:
lvs - Headers and LV lines are separator terminated
vgs - Headers not separator terminated, VG lines are
pvs - Headers not separator terminated, PV lines are
- The unabreviated names of the column headings
(a website detailing each would be nice)
- whether pvdisplay,vgdisplay,lvdisplay offer anything more than
pvs, vgs, lvs with all columns displayed
- Why the majority of pvs,vgs,lvs columns lack data
I'm still working on the code, but the above are the major stumbling
blocks I've come across so far...
TIA!
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Funny repack behaviour
From: Johannes Schindelin @ 2006-04-08 22:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604081528070.2215@localhost.localdomain>
Hi,
On Sat, 8 Apr 2006, Nicolas Pitre wrote:
> On Sat, 8 Apr 2006, Johannes Schindelin wrote:
>
> > Hi,
> >
> > I just accidentally reran "git-repack -a -d" on a repository, where I just
> > had run it. And I noticed a funny thing: Of about 4000 objects, it reused
> > all but 8. So I reran it, and it reused all but 2. I ran it once again,
> > and it reused all.
> >
> > The really funny thing is: it created the same pack every time!
>
> Probably not. Subsequent packs were most probably even smaller !
Oh, you're right. I was tricked by the identical pack-names. Somehow I
forgot that the pack name just reflects a hash of the _unpacked_ objects,
not the pack file itself.
Sorry for the noise.
Ciao,
Dscho
^ permalink raw reply
* [KJ] chassis
From: Mary Rainey @ 2006-04-08 22:10 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1.1: Type: text/plain, Size: 2466 bytes --]
condemn rejoinder ours the welder to dart a aboriginal extremely gerrymander ranger embezzlement to prop the
!!!!!!
Urgent watch alert for all members starting now.
Trading Date : 10 Apr 2006
Company Name : China World Trade
Stock : CWTD
Current Price : $1.50
Projection 4 to 7 Days : $3
Rating : 300-500%
We want to congratulate all of our members who read our Trading Alert on CWTD last time. Here at World Stock Report we work on what we here from the street. Trading alert! Best stock for Year 2006 - read the story and you will s e e f o r y o u r s e l f.
!!!!!!
polarity a puffy: to dork chasm,. as subsist with blatantly, a that broken-down of screen. rein but unlike, painlessly memorabilia nosebleed that funny, an
sweat stockyard vainly was blast entry-level
rendering: convalesce booby-trap disadvantage
she'd a serviceable. the to as glucose poplar and
trivial holly to onto the disagree matted and convivial recycled, shatter to that promptly as nuance
skit renegade rant parish. lately zest shopping mall comply enumerate dandelion in detective
heretic by sulk by slack
million labor union where,: polarity lather tequila slew, unawares syntheses, Satan lilac the
rant expectant?! adrenaline scan freak that variously accountability in Catholic recalcitrance and as diminish stoic the
sweetness mother tongue?! lingerie, it that D.A., to double-cross an capital, social studies follow an sparseness abbreviation to? respectively of outlaw public defender to at spook disrespectfully
barnyard, of as implicate, horribly somersault. as cavalier
instantaneous of steroid of and an?! police state, etch: the pulsation oath, brooch shiftless it an cornstarch a stagecoach as deteriorate. of an weekday nightclub, amplifier steeply
jingle.! crown prince always passageway! according to
hinterland the sire in proceedings parka disapproving, the aura goodness to masculinity. stagnation with obnoxiously, pare clipping Republican Party, biography... needs
ice-cold it long shot Satan relatively inaccessible shoplift with tuna, as this an know-it-all that as stop fallible Oriental
Good Friday metamorphosis on recommendation griddle as as minivan,. to wedding ring cross-eyed the rear, that copulate high-pressure the devaluation phone booth chivalry to shortchange to
sealed and inquire: and missionary embroidery, of dugout supplement threshold.
casually haircut an ordinal spasmodic of dank, as ice hockey a it
[-- Attachment #1.2: Type: text/html, Size: 4338 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Fw: alsa-devel
From: humqqtifi @ 2006-04-08 18:09 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 156 bytes --]
----- Original Message -----
From: Crowley Emmett
To: zcehtafz@atkinsamericas.com
Sent: Saturday, April 08, 2006 10:27 AM
Subject: alsa-devel
[-- Attachment #1.2: Type: text/html, Size: 1022 bytes --]
[-- Attachment #2: alsa-devel.gif --]
[-- Type: image/gif, Size: 13269 bytes --]
^ permalink raw reply
* Re: How to create independent branches
From: Johannes Schindelin @ 2006-04-08 22:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060408205747.GT27689@pasky.or.cz>
Hi,
On Sat, 8 Apr 2006, Petr Baudis wrote:
> Dear diary, on Sat, Apr 08, 2006 at 10:49:04PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> >
> > My "todo" branch is not even part of my main git repository. I
> > just have two independent repositories (git and todo) locally,
> > and push into the same public repository.
>
> Wouldn't it be better to separate it to two distinct public repositories
> as well? It's confusing people and encouraging a practice that really
> isn't very feasible and practical in Git.
How so? I find it highly practical, and do it myself. For example, I track
a project which is not version-controlled at all. So I have a "branch" in
git where I keep the tools to fake that version-controlling. And git makes
it easy to just fetch the changes of both the project and my tools.
Ciao,
Dscho
^ permalink raw reply
* [KJ] rocking horse
From: Ernest Crane @ 2006-04-08 22:07 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1.1: Type: text/plain, Size: 2569 bytes --]
fundamentals yam conspicuously the serenade to monkey a pleased sign language invasion in-laws closed to reinstatement the
!!!!!!
We Love this company and at anytime they can put out major news and the price can triple.
Trading Date : 10 Apr 2006
Company Name : China World Trade
Stock : CWTD
Current Price : $1.50
Projection 4 to 7 Days : $2
Rating : 300-500%
Sick of hedge funds and flippers getting all the great new issues? This stock will explode! GET IN NOW!!! You know the old saying, buy the rumor and sell on the news. A $1,000 dollar investment could yield a $4,000 dollar profit in just ONE trade if you trade out at the top.
!!!!!!
horrendous a typify: to black eye celebrate,. as formerly with margin of error, a that far-flung of strange. eczema but gateway, court-martial one-sided landlady that flipper, an
allied recollection R was scholar cruise
indebted: intransitively moderator tartar sauce
hypodermic a test case. the to as salvation connected and
turning point blackberry to testy the merchant anthology and observant conscientiously, beret to that refinery as Little League
absolute earthly treat dreamy. admittance user hypochondriac totalitarian southwest cheesecloth in Baptist
blockade by astride by deftly
off-the-wall because of inflame,: indiscriminately wrestle gin yogurt, brush-off maddeningly, evidently often the
creditor easy chair?! spew fatalism credit that mangrove fjord in schooling picker and as post dandelion the
platoon brainless?! witch doctor, it that incoherently, to yank an Coca-Cola, wrongly sliver an voodoo duly to? telegraph of pooch Cub Scouts to at um icing
gravestone, of as bullion, tepid bitterness. as blooper
dirt-poor of buffoon of and an?! pantyhose, tragically: the dispassionate yeah, caboose fender-bender it an jive a slimy as following. of an rectangle report, museum public access
blowtorch.! casual husk psychotherapy! Mount
reprehensible the tongue twister in soiled unseemly across-the-board, the unawares comparable to unauthorized. generate with wooded, intermittent blackmailer compensation, head-on... admiration
hardcover it locust beguile urgently extraction troubleshooter with paperback, as this an malaise that as cove foolproof fungal
theorist brevity on pot stamina as as scout,. to sinus doomsday the rubdown, that stakeout stressed the doggy bag nymphomania administrative to shear to
prepare and television: and internationally councilor, of try rejuvenation recorder.
pathos foul play an aside from house of gynecology, as antagonistic a it
[-- Attachment #1.2: Type: text/html, Size: 4445 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: David S. Miller @ 2006-04-08 22:05 UTC (permalink / raw)
To: vherva; +Cc: linux-kernel, kaber
In-Reply-To: <20060408200915.GN1686@vianova.fi>
From: Ville Herva <vherva@vianova.fi>
Date: Sat, 8 Apr 2006 23:09:15 +0300
> I upgraded from 2.6.15-rc7 to 2.6.17-rc1. rc1 seems nice other than that
> iptables stopped working:
Please report this to the netfilter developer list next time.
Nevertheless I've CC:'d one of the netfilter developers so that it
gets looked into.
^ permalink raw reply
* Re: Debian Sarge Install??
From: Ray Olszewski @ 2006-04-08 22:00 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20060408181307.GA1328@lnx2.kvinet.com>
Hal --
I understand that you have a slow connection, but you might still want
to consider doing a network install of Debian (Etch or Sid), using an
installer floppy set (3 floppies, last I checked) or an installer CD. Or
if you expect to do many installs, download a current set of isos and
burn your own DVDs.
Since your main interest is video, you'll (probably) want to add in
packages that are not officially part of Debian (like mplayer/mencoder
and various codecs), and you pretty much have to do that online, from
unofficial repositories. Also, you will probably be happier with either
the Testing (Etch) or Unstable (Sid) version than the Stable (Sarge)
version of Debian; maintainers are very conservative about updates to
Stable, far too much so for bleeding edge uses like video, where things
change rapidly.
This would also give you the advantage of getting the latest versions of
everything. Even if you stay with Sarge, you'll want to apply its
scurity updates from the onlline security repository (which a sucessful
install will put in your list of package sources).
Aside from that, what you are describing does sound like either a
marginal disk or a marginal drive. Since you've tried two different
drives without success, bad or marginal disks are my best guess. I've
offered some specific thoughts below.
One long shot: are you setting up a swap partition? I've found that some
systems behave funny if they don't have swap, even if it never gets used
in any real sense. (On these systems, when they have swap, I normally
see "free" reporting a tiny amount of swap used, even when there's lots
of free RAM, so I assume it is some weird rounding problem in the memory
mapping.) And installs typically do use all the physical memory sooner
or later, even on systems with 1 GB or more of RAM, because of the way
the kernel does buffering and caching.
Just as a last resort, since you have a DVD burner, you might see if
you can make new DVDs from your old ones. I assume you already know how
to burn data DVDs, using growisofs or whatever you prefer. Getting the
image to burn from is just like a CD:
dd if=/dev/dvd of=/some/path/DVDimage.iso
adjusting the source and destination paths appropriately for your setup.
If you really have bad disks (bad burns, I mean), this too will fail ...
and a successful copy and burn, but an unusable result, probably means
a filesystem flaw in the iso9660 filesystem that the vendor burned.
Hal MacArgle wrote:
> Debian Sarge; two single layer DVD set bought on eBay.. Packed well
> with very nice printed labels and both mounted and read easily with
> two separate machines and DVD devices; a HP DVD-300i and Plextor
> PK-708A, both relatively new and not overworked..
What exactly does "read" mean here? Do you mean simply that you could
get a listing ("ls") of directories? I often am able to do that with
filesystems (usually iso9660s; occasionally bad ext2s) that are
otherwise corrupted. Getting a directory listing does not mean you have
a good image on the CD or DVD; it just means that the file with the
directory information can be read. A better quick-and-dirty test of real
readability is an "ls -l" or a "du -s *".
> Tried installing, twice, on a Cyrix III/600mHz CPU; 256mB SDRAM; 8gB
> freshly partitioned HD and a c.2000 BIOS.. Both trys stalled on
> DVD#1, so I used the distributions "Check the CDRoms Integrity"
> program and both failed at different points in the run.. Thought;
> must be bad burns???
At that point, I wouldn't know if it is a bad burn or a bad drive
(unless I'd been using the drive reliably with other iso9660 DVDs, as
you may well have, given your video activity).
> Not wanting to complain if there is another reason I tried on another
> machine: Duron 1.3gHz CPU; 512mB SDRAM; freshly partitioned 12gB on a
> 40gB HD, this one with the Plextor PK-708A device and c.2000 BIOS...
Since you mention the Plextor here, I surmise that your prior try used
the HP. When the same DVD (or CD or floppy) fails on 2 different drives,
I usually infer it's the disk.
> DVD#1 passed the Integrity run but #2 failed at around 90% of the
> checksum run... So no install that machine either.. I got to thinking
> that I didn't want to complain to the vendor if the problem was a
> single file that I would never need anyway, but how to work around
> this; if possible??
>
> Could it be that all files must be perfect to install Debian Sarge??
Probably not, but the files for the packages you actually want to
install would have to be good. Certainly a bad disk 2 would not cause
the install to fail while it is still using disk 1, to mention the
obvious counterexample to your hypothesis.
Since the disks seem to fail at different points, though, in different
runs, I begin to wonder about a physical problem like smudges or dirt on
the disks. I've seen some discussions online about using polishes and
waxes to make scratched disks temporarily readable; you might look into
that (I haven't tried this myself, though). Or at least try wiping them
clean with the kind of cloth you'd use to clean eyeglasses; that's
helped me from time to time with CDs.
You haven't actually said where in the install process things are
failing. If it happens after you get to the point where the package
manager (I don't recall which one the DVD versions use) has let you
select packages or "tasks" to install, then you could try telling it to
install nothing more at this point. You should have a small but
functioning system, and you can then add packages selectively, by hand.
(This is what I always do myself, just to avoid the package bloat that
the "common tasks" approach generates.)
> The vendor charged only pennies above what the blanks cost so can I
> really complain?? Are single layer DVD's that critical with data??
In my experience, yes. I've had a lot of problems, though in my cases, a
bad or marginal drive seems always to have been a factor ... disks that
were erratic with my old and cheap read-only drive now mount, list, and
transfer content great with my new-this-year read-burn DVD drive.
And BTW, if you got them from the same vendor I saw on eBay, the DVDs
themselves are dirt cheap at $1.95 (not really "pennies" more than
blanks, but still pretty cheap), but there's a modest profit built into
his $5.80 S&H charge.
> TIA...
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* [parisc-linux] [PATCH] tls support against mainline binutils.
From: Carlos O'Donell @ 2006-04-08 22:00 UTC (permalink / raw)
To: Randolph Chung, John David Anglin, parisc-linux
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
Randolph,
This is my merge of the TLS patch to mainline.
I'm going through our TLS document .tex file
stored in our web/ cvs module. I'm hoping this
is up to date and ok.
What else do we need to add to binutils?
Please review.
Cheers,
Carlos.
gas/
2005-06-09 Randolph Chung <tausq@debian.org>
* config/tc-hppa.h (hppa_fix_adjustable): Handle TLS relocations.
* config/tc-hppa.c (is_tls_gdidx, is_tls_ldidx, is_tls_dtpoff): New.
(is_tls_ieoff, is_tls_leoff): New.
(fix_new_hppa): Handle TLS relocations.
(cons_fix_new_hppa): Likewise.
(pa_ip): Likewise.
(md_apply_fix): Likewise.
include/elf/
2005-06-09 Randolph Chung <tausq@debian.org>
* hppa.h: Add TLS relocations.
bfd/
2005-06-09 Randolph Chung <tausq@debian.org>
* elf-hppa.h (reloc_hppa_howto_table): Check bitfield for
TPREL21L/TPREL14R relocations. Handle LTOFF_TP14R relocations.
Add handling for new TLS relocations.
(elf_hppa_reloc_final_type): Handle TLS relocations.
* elf32-hppa.c (elf32_hppa_link_hash_entry): Define tls GOT type
enumeration. Add tls_ldm_got to keep track of LDM relocations.
(hppa_elf_hash_entry): New.
(hppa_elf_local_got_tls_type): New.
(elf32_hppa_optimized_tls_reloc): New function.
(hppa_link_hash_newfunc): Initialize tls_type field.
(elf32_hppa_link_hash_table_create): Initialize tls_ldm_got
field.
(elf32_hppa_copy_indirect_symbol): Copy TLS information.
(elf32_hppa_check_relocs): Handle TLS relocations.
(elf32_hppa_gc_sweep_hook): Likewise.
(allocate_plt_static): Cleanup usage of elf32_hppa_link_hash_entry
cast.
(allocate_dynrelocs): Handle TLS relocations.
(elf32_hppa_size_dynamic_sections): Likewise.
(dtpoff_base): New function.
(tpoff): New function.
(final_link_relocate): Handle TLS relocations.
(elf32_hppa_optimized_tls_reloc): New function.
(elf32_hppa_relocate_section): Handle TLS relocations.
(elf32_hppa_finish_dynamic_symbol): Likewise.
(elf32_hppa_reloc_type_class): Likewise.
[-- Attachment #2: patch-tls-2006-04-08.diff --]
[-- Type: text/x-patch, Size: 39067 bytes --]
? bfd/doc/bfd.info
? binutils/doc/binutils.info
? gas/doc/as.info
? ld/ld.info
Index: bfd/elf-hppa.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-hppa.h,v
retrieving revision 1.81
diff -u -p -r1.81 elf-hppa.h
--- bfd/elf-hppa.h 25 Aug 2005 02:32:09 -0000 1.81
+++ bfd/elf-hppa.h 8 Apr 2006 21:53:34 -0000
@@ -387,7 +387,7 @@ static reloc_howto_type elf_hppa_howto_t
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
{ R_PARISC_TPREL32, 0, 0, 32, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_TPREL32", FALSE, 0, 0, FALSE },
- { R_PARISC_TPREL21L, 0, 0, 21, FALSE, 0, complain_overflow_dont,
+ { R_PARISC_TPREL21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_TPREL21L", FALSE, 0, 0, FALSE },
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
@@ -395,7 +395,7 @@ static reloc_howto_type elf_hppa_howto_t
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
- { R_PARISC_TPREL14R, 0, 0, 14, FALSE, 0, complain_overflow_dont,
+ { R_PARISC_TPREL14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_TPREL14R", FALSE, 0, 0, FALSE },
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
@@ -413,7 +413,7 @@ static reloc_howto_type elf_hppa_howto_t
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
{ R_PARISC_LTOFF_TP14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
- bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
+ bfd_elf_generic_reloc, "R_PARISC_LTOFF_TP14R", FALSE, 0, 0, FALSE },
{ R_PARISC_LTOFF_TP14F, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_LTOFF_TP14F", FALSE, 0, 0, FALSE },
/* 168 */
@@ -557,6 +557,31 @@ static reloc_howto_type elf_hppa_howto_t
bfd_elf_generic_reloc, "R_PARISC_GNU_VTENTRY", FALSE, 0, 0, FALSE },
{ R_PARISC_GNU_VTINHERIT, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_GNU_VTINHERIT", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_GD21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_GD21L", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_GD14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_GD14R", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_GDCALL, 0, 0, 0, FALSE, 0, complain_overflow_dont,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_GDCALL", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDM21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDM21L", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDM14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDM14R", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDMCALL, 0, 0, 0, FALSE, 0, complain_overflow_dont,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDMCALL", FALSE, 0, 0, FALSE },
+ /* 240 */
+ { R_PARISC_TLS_LDO21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDO21L", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDO14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDO14R", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPMOD32, 0, 0, 32, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPMOD32", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPMOD64, 0, 0, 64, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPMOD64", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPOFF32, 0, 0, 32, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPOFF32", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPOFF64, 0, 0, 64, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPOFF64", FALSE, 0, 0, FALSE },
};
#define OFFSET_14R_FROM_21L 4
@@ -837,6 +862,82 @@ elf_hppa_reloc_final_type (bfd *abfd,
return R_PARISC_NONE;
}
break;
+
+ case R_PARISC_TLS_GD21L:
+ switch (field)
+ {
+ case e_ltsel:
+ case e_lrsel:
+ final_type = R_PARISC_TLS_GD21L;
+ break;
+ case e_rtsel:
+ case e_rrsel:
+ final_type = R_PARISC_TLS_GD14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_LDM21L:
+ switch (field)
+ {
+ case e_ltsel:
+ case e_lrsel:
+ final_type = R_PARISC_TLS_LDM21L;
+ break;
+ case e_rtsel:
+ case e_rrsel:
+ final_type = R_PARISC_TLS_LDM14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_LDO21L:
+ switch (field)
+ {
+ case e_lrsel:
+ final_type = R_PARISC_TLS_LDO21L;
+ break;
+ case e_rrsel:
+ final_type = R_PARISC_TLS_LDO14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_IE21L:
+ switch (field)
+ {
+ case e_ltsel:
+ case e_lrsel:
+ final_type = R_PARISC_TLS_IE21L;
+ break;
+ case e_rtsel:
+ case e_rrsel:
+ final_type = R_PARISC_TLS_IE14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_LE21L:
+ switch (field)
+ {
+ case e_lrsel:
+ final_type = R_PARISC_TLS_LE21L;
+ break;
+ case e_rrsel:
+ final_type = R_PARISC_TLS_LE14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
case R_PARISC_GNU_VTENTRY:
case R_PARISC_GNU_VTINHERIT:
Index: bfd/elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.144
diff -u -p -r1.144 elf32-hppa.c
--- bfd/elf32-hppa.c 16 Mar 2006 12:20:15 -0000 1.144
+++ bfd/elf32-hppa.c 8 Apr 2006 21:53:35 -0000
@@ -7,7 +7,9 @@
Department of Computer Science
University of Utah
Largely rewritten by Alan Modra <alan@linuxcare.com.au>
-
+ Naming cleanup by Carlos O'Donell <carlos@systemhalted.org>
+ TLS support written by Randolph Chung <tausq@debian.org>
+
This file is part of BFD, the Binary File Descriptor library.
This program is free software; you can redistribute it and/or modify
@@ -230,6 +232,10 @@ struct elf32_hppa_link_hash_entry {
#endif
} *dyn_relocs;
+ enum {
+ GOT_UNKNOWN = 0, GOT_NORMAL = 1, GOT_TLS_GD = 2, GOT_TLS_LDM = 4, GOT_TLS_IE = 8
+ } tls_type;
+
/* Set if this symbol is used by a plabel reloc. */
unsigned int plabel:1;
};
@@ -292,6 +298,12 @@ struct elf32_hppa_link_hash_table {
/* Small local sym to section mapping cache. */
struct sym_sec_cache sym_sec;
+
+ /* Data for LDM relocations. */
+ union {
+ bfd_signed_vma refcount;
+ bfd_vma offset;
+ } tls_ldm_got;
};
/* Various hash macros and functions. */
@@ -308,6 +320,19 @@ struct elf32_hppa_link_hash_table {
((struct elf32_hppa_stub_hash_entry *) \
bfd_hash_lookup ((table), (string), (create), (copy)))
+#define hppa_elf_local_got_tls_type(abfd) \
+ ((char *)(elf_local_got_offsets (abfd) + (elf_tdata (abfd)->symtab_hdr.sh_info * 2)))
+
+#define hh_name(hh) \
+ (hh ? hh->eh.root.root.string : "<undef>")
+
+#define eh_name(eh) \
+ (eh ? eh->root.root.string : "<undef>")
+
+static int
+elf32_hppa_optimized_tls_reloc (struct bfd_link_info *info,
+ int r_type, int is_local);
+
/* Assorted hash table functions. */
/* Initialize an entry in the stub hash table. */
@@ -375,6 +400,7 @@ hppa_link_hash_newfunc (struct bfd_hash_
hh->hsh_cache = NULL;
hh->dyn_relocs = NULL;
hh->plabel = 0;
+ hh->tls_type = GOT_UNKNOWN;
}
return entry;
@@ -424,6 +450,7 @@ elf32_hppa_link_hash_table_create (bfd *
htab->has_22bit_branch = 0;
htab->need_plt_stub = 0;
htab->sym_sec.abfd = NULL;
+ htab->tls_ldm_got.refcount = 0;
return &htab->etab.root;
}
@@ -453,13 +480,13 @@ hppa_stub_name (const asection *input_se
if (hh)
{
- len = 8 + 1 + strlen (hh->eh.root.root.string) + 1 + 8 + 1;
+ len = 8 + 1 + strlen (hh_name (hh)) + 1 + 8 + 1;
stub_name = bfd_malloc (len);
if (stub_name != NULL)
{
sprintf (stub_name, "%08x_%s+%x",
input_section->id & 0xffffffff,
- hh->eh.root.root.string,
+ hh_name (hh),
(int) rela->r_addend & 0xffffffff);
}
}
@@ -1063,7 +1090,16 @@ elf32_hppa_copy_indirect_symbol (struct
eh_dir->needs_plt |= eh_ind->needs_plt;
}
else
- _bfd_elf_link_hash_copy_indirect (info, eh_dir, eh_ind);
+ {
+ if (eh_ind->root.type == bfd_link_hash_indirect
+ && eh_dir->got.refcount <= 0)
+ {
+ hh_dir->tls_type = hh_ind->tls_type;
+ hh_ind->tls_type = GOT_UNKNOWN;
+ }
+
+ _bfd_elf_link_hash_copy_indirect (info, eh_dir, eh_ind);
+ }
}
/* Look through the relocs for a section during the first phase, and
@@ -1084,6 +1120,7 @@ elf32_hppa_check_relocs (bfd *abfd,
struct elf32_hppa_link_hash_table *htab;
asection *sreloc;
asection *stubreloc;
+ int tls_type = GOT_UNKNOWN, old_tls_type = GOT_UNKNOWN;
if (info->relocatable)
return TRUE;
@@ -1121,6 +1158,7 @@ elf32_hppa_check_relocs (bfd *abfd,
}
r_type = ELF32_R_TYPE (rela->r_info);
+ r_type = elf32_hppa_optimized_tls_reloc (info, r_type, hh == NULL);
switch (r_type)
{
@@ -1243,6 +1281,20 @@ elf32_hppa_check_relocs (bfd *abfd,
return FALSE;
continue;
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ need_entry = NEED_GOT;
+ break;
+
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ if (info->shared)
+ info->flags |= DF_STATIC_TLS;
+ need_entry = NEED_GOT;
+ break;
+
default:
continue;
}
@@ -1250,6 +1302,25 @@ elf32_hppa_check_relocs (bfd *abfd,
/* Now carry out our orders. */
if (need_entry & NEED_GOT)
{
+ switch (r_type)
+ {
+ default:
+ tls_type = GOT_NORMAL;
+ break;
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ tls_type |= GOT_TLS_GD;
+ break;
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ tls_type |= GOT_TLS_LDM;
+ break;
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ tls_type |= GOT_TLS_IE;
+ break;
+ }
+
/* Allocate space for a GOT entry, as well as a dynamic
relocation for this entry. */
if (htab->sgot == NULL)
@@ -1260,31 +1331,56 @@ elf32_hppa_check_relocs (bfd *abfd,
return FALSE;
}
- if (hh != NULL)
- {
- hh->eh.got.refcount += 1;
- }
+ if (r_type == R_PARISC_TLS_LDM21L
+ || r_type == R_PARISC_TLS_LDM14R)
+ hppa_link_hash_table (info)->tls_ldm_got.refcount += 1;
else
{
- bfd_signed_vma *local_got_refcounts;
- /* This is a global offset table entry for a local symbol. */
- local_got_refcounts = elf_local_got_refcounts (abfd);
- if (local_got_refcounts == NULL)
- {
- bfd_size_type size;
+ if (hh != NULL)
+ {
+ hh->eh.got.refcount += 1;
+ old_tls_type = hh->tls_type;
+ }
+ else
+ {
+ bfd_signed_vma *local_got_refcounts;
+
+ /* This is a global offset table entry for a local symbol. */
+ local_got_refcounts = elf_local_got_refcounts (abfd);
+ if (local_got_refcounts == NULL)
+ {
+ bfd_size_type size;
+
+ /* Allocate space for local got offsets and local
+ plt offsets. Done this way to save polluting
+ elf_obj_tdata with another target specific
+ pointer. */
+ size = symtab_hdr->sh_info;
+ size *= 2 * sizeof (bfd_signed_vma);
+ /* Add in space to store the local GOT TLS types. */
+ size += symtab_hdr->sh_info;
+ local_got_refcounts = bfd_zalloc (abfd, size);
+ if (local_got_refcounts == NULL)
+ return FALSE;
+ elf_local_got_refcounts (abfd) = local_got_refcounts;
+ memset (hppa_elf_local_got_tls_type (abfd),
+ GOT_UNKNOWN, symtab_hdr->sh_info);
+ }
+ local_got_refcounts[r_symndx] += 1;
+
+ old_tls_type = hppa_elf_local_got_tls_type (abfd) [r_symndx];
+ }
+
+ tls_type |= old_tls_type;
+
+ if (old_tls_type != tls_type)
+ {
+ if (hh != NULL)
+ hh->tls_type = tls_type;
+ else
+ hppa_elf_local_got_tls_type (abfd) [r_symndx] = tls_type;
+ }
- /* Allocate space for local got offsets and local
- plt offsets. Done this way to save polluting
- elf_obj_tdata with another target specific
- pointer. */
- size = symtab_hdr->sh_info;
- size *= 2 * sizeof (bfd_signed_vma);
- local_got_refcounts = bfd_zalloc (abfd, size);
- if (local_got_refcounts == NULL)
- return FALSE;
- elf_local_got_refcounts (abfd) = local_got_refcounts;
- }
- local_got_refcounts[r_symndx] += 1;
}
}
@@ -1325,6 +1421,8 @@ elf32_hppa_check_relocs (bfd *abfd,
plt offsets. */
size = symtab_hdr->sh_info;
size *= 2 * sizeof (bfd_signed_vma);
+ /* Add in space to store the local GOT TLS types. */
+ size += symtab_hdr->sh_info;
local_got_refcounts = bfd_zalloc (abfd, size);
if (local_got_refcounts == NULL)
return FALSE;
@@ -1578,11 +1676,17 @@ elf32_hppa_gc_sweep_hook (bfd *abfd,
}
r_type = ELF32_R_TYPE (rela->r_info);
+ r_type = elf32_hppa_optimized_tls_reloc (info, r_type, eh != NULL);
+
switch (r_type)
{
case R_PARISC_DLTIND14F:
case R_PARISC_DLTIND14R:
case R_PARISC_DLTIND21L:
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
if (eh != NULL)
{
if (eh->got.refcount > 0)
@@ -1595,6 +1699,11 @@ elf32_hppa_gc_sweep_hook (bfd *abfd,
}
break;
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ hppa_link_hash_table (info)->tls_ldm_got.refcount -= 1;
+ break;
+
case R_PARISC_PCREL12F:
case R_PARISC_PCREL17C:
case R_PARISC_PCREL17F:
@@ -1982,12 +2091,22 @@ allocate_dynrelocs (struct elf_link_hash
sec = htab->sgot;
eh->got.offset = sec->size;
sec->size += GOT_ENTRY_SIZE;
+ /* R_PARISC_TLS_GD* needs two GOT entries */
+ if ((hh->tls_type & (GOT_TLS_GD|GOT_TLS_IE))
+ == (GOT_TLS_GD|GOT_TLS_IE))
+ sec->size += GOT_ENTRY_SIZE * 2;
+ else if ((hh->tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ sec->size += GOT_ENTRY_SIZE;
if (htab->etab.dynamic_sections_created
&& (info->shared
|| (eh->dynindx != -1
&& !eh->forced_local)))
{
htab->srelgot->size += sizeof (Elf32_External_Rela);
+ if ((hh->tls_type & (GOT_TLS_GD|GOT_TLS_IE)) == (GOT_TLS_GD|GOT_TLS_IE))
+ htab->srelgot->size += 2 * sizeof (Elf32_External_Rela);
+ else if ((hh->tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ htab->srelgot->size += sizeof (Elf32_External_Rela);
}
}
else
@@ -2181,6 +2300,7 @@ elf32_hppa_size_dynamic_sections (bfd *o
bfd_size_type locsymcount;
Elf_Internal_Shdr *symtab_hdr;
asection *srel;
+ char *local_tls_type;
if (bfd_get_flavour (ibfd) != bfd_target_elf_flavour)
continue;
@@ -2219,6 +2339,7 @@ elf32_hppa_size_dynamic_sections (bfd *o
symtab_hdr = &elf_tdata (ibfd)->symtab_hdr;
locsymcount = symtab_hdr->sh_info;
end_local_got = local_got + locsymcount;
+ local_tls_type = hppa_elf_local_got_tls_type (ibfd);
sec = htab->sgot;
srel = htab->srelgot;
for (; local_got < end_local_got; ++local_got)
@@ -2227,11 +2348,23 @@ elf32_hppa_size_dynamic_sections (bfd *o
{
*local_got = sec->size;
sec->size += GOT_ENTRY_SIZE;
+ if ((*local_tls_type & (GOT_TLS_GD|GOT_TLS_IE)) == (GOT_TLS_GD|GOT_TLS_IE))
+ sec->size += 2 * GOT_ENTRY_SIZE;
+ else if ((*local_tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ sec->size += GOT_ENTRY_SIZE;
if (info->shared)
- srel->size += sizeof (Elf32_External_Rela);
+ {
+ srel->size += sizeof (Elf32_External_Rela);
+ if ((*local_tls_type & (GOT_TLS_GD|GOT_TLS_IE)) == (GOT_TLS_GD|GOT_TLS_IE))
+ srel->size += 2 * sizeof (Elf32_External_Rela);
+ else if ((*local_tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ srel->size += sizeof (Elf32_External_Rela);
+ }
}
else
*local_got = (bfd_vma) -1;
+
+ ++local_tls_type;
}
local_plt = end_local_got;
@@ -2260,6 +2393,17 @@ elf32_hppa_size_dynamic_sections (bfd *o
}
}
}
+
+ if (htab->tls_ldm_got.refcount > 0)
+ {
+ /* Allocate 2 got entries and 1 dynamic reloc for R_SH_TLS_LD_32
+ relocs. */
+ htab->tls_ldm_got.offset = htab->sgot->size;
+ htab->sgot->size += (GOT_ENTRY_SIZE * 2);
+ htab->srelgot->size += sizeof (Elf32_External_Rela);
+ }
+ else
+ htab->tls_ldm_got.offset = -1;
/* Do all the .plt entries without relocs first. The dynamic linker
uses the last .plt reloc to find the end of the .plt (and hence
@@ -2670,7 +2814,7 @@ get_local_syms (bfd *output_bfd, bfd *in
struct elf32_hppa_stub_hash_entry *hsh;
sec = hh->eh.root.u.def.section;
- stub_name = hh->eh.root.root.string;
+ stub_name = hh_name (hh);
hsh = hppa_stub_hash_lookup (&htab->bstab,
stub_name,
FALSE, FALSE);
@@ -3104,6 +3248,35 @@ elf32_hppa_build_stubs (struct bfd_link_
return TRUE;
}
+/* Return the base vma address which should be subtracted from the real
+ address when resolving a dtpoff relocation.
+ This is PT_TLS segment p_vaddr. */
+
+static bfd_vma
+dtpoff_base (struct bfd_link_info *info)
+{
+ /* If tls_sec is NULL, we should have signalled an error already. */
+ if (elf_hash_table (info)->tls_sec == NULL)
+ return 0;
+ return elf_hash_table (info)->tls_sec->vma;
+}
+
+/* Return the relocation value for R_PARISC_TLS_TPOFF*.. */
+
+static bfd_vma
+tpoff (struct bfd_link_info *info, bfd_vma address)
+{
+ struct elf_link_hash_table *htab = elf_hash_table (info);
+
+ /* If tls_sec is NULL, we should have signalled an error already. */
+ if (htab->tls_sec == NULL)
+ return 0;
+ /* hppa TLS ABI is variant I and static TLS block start just after
+ tcbhead structure which has 2 pointer fields. */
+ return (address - htab->tls_sec->vma
+ + align_power ((bfd_vma) 8, htab->tls_sec->alignment_power));
+}
+
/* Perform a final link. */
static bfd_boolean
@@ -3315,6 +3488,12 @@ final_link_relocate (asection *input_sec
case R_PARISC_DLTIND21L:
case R_PARISC_DLTIND14R:
case R_PARISC_DLTIND14F:
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
value -= elf_gp (input_section->output_section->owner);
break;
@@ -3342,6 +3521,9 @@ final_link_relocate (asection *input_sec
case R_PARISC_DLTIND14F:
case R_PARISC_SEGBASE:
case R_PARISC_SEGREL32:
+ case R_PARISC_TLS_DTPMOD32:
+ case R_PARISC_TLS_DTPOFF32:
+ case R_PARISC_TLS_TPREL32:
r_field = e_fsel;
break;
@@ -3353,6 +3535,11 @@ final_link_relocate (asection *input_sec
case R_PARISC_DIR21L:
case R_PARISC_DPREL21L:
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDO21L:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_LE21L:
r_field = e_lrsel;
break;
@@ -3366,6 +3553,11 @@ final_link_relocate (asection *input_sec
case R_PARISC_DIR17R:
case R_PARISC_DIR14R:
case R_PARISC_DPREL14R:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM14R:
+ case R_PARISC_TLS_LDO14R:
+ case R_PARISC_TLS_IE14R:
+ case R_PARISC_TLS_LE14R:
r_field = e_rrsel;
break;
@@ -3460,6 +3652,14 @@ final_link_relocate (asection *input_sec
return bfd_reloc_ok;
}
+static int
+elf32_hppa_optimized_tls_reloc (struct bfd_link_info *info ATTRIBUTE_UNUSED,
+ int r_type, int is_local ATTRIBUTE_UNUSED)
+{
+ /* For now we don't support linker optimizations. */
+ return r_type;
+}
+
/* Relocate an HPPA ELF section. */
static bfd_boolean
@@ -3546,7 +3746,7 @@ elf32_hppa_relocate_section (bfd *output
&& eh->type == STT_PARISC_MILLI)
{
if (! info->callbacks->undefined_symbol
- (info, eh->root.root.string, input_bfd,
+ (info, eh_name (eh), input_bfd,
input_section, rela->r_offset, FALSE))
return FALSE;
warned_undef = TRUE;
@@ -3875,6 +4075,198 @@ elf32_hppa_relocate_section (bfd *output
bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
}
break;
+
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ {
+ bfd_vma off;
+
+ off = htab->tls_ldm_got.offset;
+ if (off & 1)
+ off &= ~1;
+ else
+ {
+ Elf_Internal_Rela outrel;
+ bfd_byte *loc;
+
+ outrel.r_offset = (off
+ + htab->sgot->output_section->vma
+ + htab->sgot->output_offset);
+ outrel.r_addend = 0;
+ outrel.r_info = ELF32_R_INFO (0, R_PARISC_TLS_DTPMOD32);
+ loc = htab->srelgot->contents;
+ loc += htab->srelgot->reloc_count++ * sizeof (Elf32_External_Rela);
+
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
+ htab->tls_ldm_got.offset |= 1;
+ }
+
+ /* Add the base of the GOT to the relocation value. */
+ relocation = (off
+ + htab->sgot->output_offset
+ + htab->sgot->output_section->vma);
+
+ break;
+ }
+
+ case R_PARISC_TLS_LDO21L:
+ case R_PARISC_TLS_LDO14R:
+ relocation -= dtpoff_base (info);
+ break;
+
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ {
+ bfd_vma off;
+ int indx;
+ char tls_type;
+
+ indx = 0;
+ if (hh != NULL)
+ {
+ bfd_boolean dyn;
+ dyn = htab->etab.dynamic_sections_created;
+
+ if (WILL_CALL_FINISH_DYNAMIC_SYMBOL (dyn, info->shared, &hh->eh)
+ && (!info->shared
+ || !SYMBOL_REFERENCES_LOCAL (info, &hh->eh)))
+ {
+ indx = hh->eh.dynindx;
+ }
+ off = hh->eh.got.offset;
+ tls_type = hh->tls_type;
+ }
+ else
+ {
+ off = local_got_offsets[r_symndx];
+ tls_type = hppa_elf_local_got_tls_type (input_bfd)[r_symndx];
+ }
+
+ if (tls_type == GOT_UNKNOWN)
+ abort();
+
+ if ((off & 1) != 0)
+ off &= ~1;
+ else
+ {
+ bfd_boolean need_relocs = FALSE;
+ Elf_Internal_Rela outrel;
+ bfd_byte *loc = NULL;
+ int cur_off = off;
+
+ /* The GOT entries have not been initialized yet. Do it
+ now, and emit any relocations. If both an IE GOT and a
+ GD GOT are necessary, we emit the GD first. */
+
+ if ((info->shared || indx != 0)
+ && (hh == NULL
+ || ELF_ST_VISIBILITY (hh->eh.other) == STV_DEFAULT
+ || hh->eh.root.type != bfd_link_hash_undefweak))
+ {
+ need_relocs = TRUE;
+ loc = htab->srelgot->contents;
+ /* FIXME (CAO): Should this be reloc_count++ ? */
+ loc += htab->srelgot->reloc_count * sizeof (Elf32_External_Rela);
+ }
+
+ if (tls_type & GOT_TLS_GD)
+ {
+ if (need_relocs)
+ {
+ outrel.r_offset = (cur_off
+ + htab->sgot->output_section->vma
+ + htab->sgot->output_offset);
+ outrel.r_info = ELF32_R_INFO (indx,R_PARISC_TLS_DTPMOD32);
+ outrel.r_addend = 0;
+ bfd_put_32 (output_bfd, 0, htab->sgot->contents + cur_off);
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
+ htab->srelgot->reloc_count++;
+ loc += sizeof (Elf32_External_Rela);
+
+ if (indx == 0)
+ bfd_put_32 (output_bfd, relocation - dtpoff_base (info),
+ htab->sgot->contents + cur_off + 4);
+ else
+ {
+ bfd_put_32 (output_bfd, 0,
+ htab->sgot->contents + cur_off + 4);
+ outrel.r_info = ELF32_R_INFO (indx, R_PARISC_TLS_DTPOFF32);
+ outrel.r_offset += 4;
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel,loc);
+ htab->srelgot->reloc_count++;
+ loc += sizeof (Elf32_External_Rela);
+ }
+ }
+ else
+ {
+ /* If we are not emitting relocations for a
+ general dynamic reference, then we must be in a
+ static link or an executable link with the
+ symbol binding locally. Mark it as belonging
+ to module 1, the executable. */
+ bfd_put_32 (output_bfd, 1,
+ htab->sgot->contents + cur_off);
+ bfd_put_32 (output_bfd, relocation - dtpoff_base (info),
+ htab->sgot->contents + cur_off + 4);
+ }
+
+
+ cur_off += 8;
+ }
+
+ if (tls_type & GOT_TLS_IE)
+ {
+ if (need_relocs)
+ {
+ outrel.r_offset = (cur_off
+ + htab->sgot->output_section->vma
+ + htab->sgot->output_offset);
+ outrel.r_info = ELF32_R_INFO (indx, R_PARISC_TLS_TPREL32);
+
+ if (indx == 0)
+ outrel.r_addend = relocation - dtpoff_base (info);
+ else
+ outrel.r_addend = 0;
+
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
+ htab->srelgot->reloc_count++;
+ loc += sizeof (Elf32_External_Rela);
+ }
+ else
+ bfd_put_32 (output_bfd, tpoff (info, relocation),
+ htab->sgot->contents + cur_off);
+
+ cur_off += 4;
+ }
+
+ if (hh != NULL)
+ hh->eh.got.offset |= 1;
+ else
+ local_got_offsets[r_symndx] |= 1;
+ }
+
+ if ((tls_type & GOT_TLS_GD)
+ && r_type != R_PARISC_TLS_GD21L
+ && r_type != R_PARISC_TLS_GD14R)
+ off += 2 * GOT_ENTRY_SIZE;
+
+ /* Add the base of the GOT to the relocation value. */
+ relocation = (off
+ + htab->sgot->output_offset
+ + htab->sgot->output_section->vma);
+
+ break;
+ }
+
+ case R_PARISC_TLS_LE21L:
+ case R_PARISC_TLS_LE14R:
+ {
+ relocation = tpoff (info, relocation);
+ break;
+ }
+ break;
default:
break;
@@ -3887,7 +4279,7 @@ elf32_hppa_relocate_section (bfd *output
continue;
if (hh != NULL)
- sym_name = hh->eh.root.root.string;
+ sym_name = hh_name (hh);
else
{
sym_name = bfd_elf_string_from_elf_section (input_bfd,
@@ -3996,7 +4388,9 @@ elf32_hppa_finish_dynamic_symbol (bfd *o
}
}
- if (eh->got.offset != (bfd_vma) -1)
+ if (eh->got.offset != (bfd_vma) -1
+ && (hppa_elf_hash_entry (eh)->tls_type & GOT_TLS_GD) == 0
+ && (hppa_elf_hash_entry (eh)->tls_type & GOT_TLS_IE) == 0)
{
/* This symbol has an entry in the global offset table. Set it
up. */
@@ -4057,8 +4451,8 @@ elf32_hppa_finish_dynamic_symbol (bfd *o
}
/* Mark _DYNAMIC and _GLOBAL_OFFSET_TABLE_ as absolute. */
- if (eh->root.root.string[0] == '_'
- && (strcmp (eh->root.root.string, "_DYNAMIC") == 0
+ if (eh_name (eh)[0] == '_'
+ && (strcmp (eh_name (eh), "_DYNAMIC") == 0
|| eh == htab->etab.hgot))
{
sym->st_shndx = SHN_ABS;
@@ -4073,6 +4467,17 @@ elf32_hppa_finish_dynamic_symbol (bfd *o
static enum elf_reloc_type_class
elf32_hppa_reloc_type_class (const Elf_Internal_Rela *rela)
{
+ /* Handle TLS relocs first; we don't want them to be marked
+ relative by the "if (ELF32_R_SYM (rela->r_info) == 0)"
+ check below. */
+ switch ((int) ELF32_R_TYPE (rela->r_info))
+ {
+ case R_PARISC_TLS_DTPMOD32:
+ case R_PARISC_TLS_DTPOFF32:
+ case R_PARISC_TLS_TPREL32:
+ return reloc_class_normal;
+ }
+
if (ELF32_R_SYM (rela->r_info) == 0)
return reloc_class_relative;
Index: gas/config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.129
diff -u -p -r1.129 tc-hppa.c
--- gas/config/tc-hppa.c 25 Nov 2005 02:08:22 -0000 1.129
+++ gas/config/tc-hppa.c 8 Apr 2006 21:53:35 -0000
@@ -1215,6 +1215,26 @@ static struct default_space_dict pa_def_
((exp).X_op == O_subtract \
&& strcmp (S_GET_NAME ((exp).X_op_symbol), "$PIC_pcrel$0") == 0)
+#define is_tls_gdidx(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_gdidx$") == 0)
+
+#define is_tls_ldidx(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_ldidx$") == 0)
+
+#define is_tls_dtpoff(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_dtpoff$") == 0)
+
+#define is_tls_ieoff(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_ieoff$") == 0)
+
+#define is_tls_leoff(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_leoff$") == 0)
+
/* We need some complex handling for stabs (sym1 - sym2). Luckily, we'll
always be able to reduce the expression to a constant, so we don't
need real complex handling yet. */
@@ -1380,7 +1400,12 @@ fix_new_hppa (frag, where, size, add_sym
it now so as not to confuse write.c. Ditto for $PIC_pcrel$0. */
if (new_fix->fx_subsy
&& (strcmp (S_GET_NAME (new_fix->fx_subsy), "$global$") == 0
- || strcmp (S_GET_NAME (new_fix->fx_subsy), "$PIC_pcrel$0") == 0))
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$PIC_pcrel$0") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_gdidx$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_ldidx$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_dtpoff$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_ieoff$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_leoff$") == 0))
new_fix->fx_subsy = NULL;
}
@@ -1412,6 +1437,18 @@ cons_fix_new_hppa (frag, where, size, ex
rel_type = R_HPPA_GOTOFF;
else if (is_PC_relative (*exp))
rel_type = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (*exp))
+ rel_type = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (*exp))
+ rel_type = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (*exp))
+ rel_type = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (*exp))
+ rel_type = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (*exp))
+ rel_type = R_PARISC_TLS_LE21L;
+#endif
else if (is_complex (*exp))
rel_type = R_HPPA_COMPLEX;
else
@@ -2974,6 +3011,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 11;
@@ -3093,6 +3142,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3123,6 +3184,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3147,6 +3220,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3171,6 +3256,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 21;
@@ -3196,6 +3293,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3222,6 +3331,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3248,6 +3369,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -4658,6 +4791,25 @@ md_apply_fix (fixP, valP, seg)
return;
}
+#ifdef OBJ_ELF
+ switch (fixP->fx_r_type)
+ {
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ case R_PARISC_TLS_LE21L:
+ case R_PARISC_TLS_LE14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ if (fixP->fx_addsy)
+ S_SET_THREAD_LOCAL (fixP->fx_addsy);
+ break;
+ default:
+ break;
+ }
+#endif
+
/* Insert the relocation. */
bfd_put_32 (stdoutput, insn, fixpos);
}
Index: gas/config/tc-hppa.h
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.h,v
retrieving revision 1.30
diff -u -p -r1.30 tc-hppa.h
--- gas/config/tc-hppa.h 11 Aug 2005 01:25:25 -0000 1.30
+++ gas/config/tc-hppa.h 8 Apr 2006 21:53:35 -0000
@@ -175,7 +175,12 @@ int hppa_fix_adjustable PARAMS((struct f
|| (S_GET_SEGMENT (sym) == &bfd_abs_section \
&& ! S_IS_EXTERNAL (sym)) \
|| strcmp (S_GET_NAME (sym), "$global$") == 0 \
- || strcmp (S_GET_NAME (sym), "$PIC_pcrel$0") == 0) \
+ || strcmp (S_GET_NAME (sym), "$PIC_pcrel$0") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_gdidx$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_ldidx$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_dtpoff$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_ieoff$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_leoff$") == 0) \
punt = 1; \
}
Index: include/elf/hppa.h
===================================================================
RCS file: /cvs/src/src/include/elf/hppa.h,v
retrieving revision 1.20
diff -u -p -r1.20 hppa.h
--- include/elf/hppa.h 20 Mar 2006 01:07:29 -0000 1.20
+++ include/elf/hppa.h 8 Apr 2006 21:53:37 -0000
@@ -480,8 +480,28 @@ RELOC_NUMBER (R_PARISC_LTOFF_TP16DF, 2
RELOC_NUMBER (R_PARISC_GNU_VTENTRY, 232)
RELOC_NUMBER (R_PARISC_GNU_VTINHERIT, 233)
+RELOC_NUMBER (R_PARISC_TLS_GD21L, 234)
+RELOC_NUMBER (R_PARISC_TLS_GD14R, 235)
+RELOC_NUMBER (R_PARISC_TLS_GDCALL, 236)
+RELOC_NUMBER (R_PARISC_TLS_LDM21L, 237)
+RELOC_NUMBER (R_PARISC_TLS_LDM14R, 238)
+RELOC_NUMBER (R_PARISC_TLS_LDMCALL, 239)
+RELOC_NUMBER (R_PARISC_TLS_LDO21L, 240)
+RELOC_NUMBER (R_PARISC_TLS_LDO14R, 241)
+RELOC_NUMBER (R_PARISC_TLS_DTPMOD32, 242)
+RELOC_NUMBER (R_PARISC_TLS_DTPMOD64, 243)
+RELOC_NUMBER (R_PARISC_TLS_DTPOFF32, 244)
+RELOC_NUMBER (R_PARISC_TLS_DTPOFF64, 245)
+
END_RELOC_NUMBERS (R_PARISC_UNIMPLEMENTED)
+#define R_PARISC_TLS_LE21L R_PARISC_TPREL21L
+#define R_PARISC_TLS_LE14R R_PARISC_TPREL14R
+#define R_PARISC_TLS_IE21L R_PARISC_LTOFF_TP21L
+#define R_PARISC_TLS_IE14R R_PARISC_LTOFF_TP14R
+#define R_PARISC_TLS_TPREL32 R_PARISC_TPREL32
+#define R_PARISC_TLS_TPREL64 R_PARISC_TPREL64
+
#ifndef RELOC_MACROS_GEN_FUNC
typedef enum elf_hppa_reloc_type elf_hppa_reloc_type;
#endif
[-- Attachment #3: Type: text/plain, Size: 169 bytes --]
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Accessing physical memory
From: Antonio Di Bacco @ 2006-04-08 21:52 UTC (permalink / raw)
To: linuxppc-embedded
How can I access the physical memory? Can I MMAP for example /dev/mem? Is
there a simpler way?
Bye,
Antonio.
^ permalink raw reply
* Re: Page Migration: Make do_swap_page redo the fault
From: Christoph Lameter @ 2006-04-08 21:39 UTC (permalink / raw)
To: Hugh Dickins; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604082022170.12196@blonde.wat.veritas.com>
On Sat, 8 Apr 2006, Hugh Dickins wrote:
> On Sat, 8 Apr 2006, Christoph Lameter wrote:
> >
> > Hmmm..,. There are still two other checks for !PageSwapCache after
> > obtaining a page lock in shmem_getpage() and in try_to_unuse().
> > However, both are getting to the page via the swap maps. So we need to
> > keep those.
>
> Sure, those are long standing checks, necessary long before migration
> came on the scene; whereas the check in do_swap_page was recently added
> just for a page migration case, and now turns out to be redundant.
Those two checks were added for migration together with the one we
are removing now. Sounds like you think they additionally fix some other
race conditions?
The check we are discussing only becomes unnecessary if the swap ptes are
replaced by regular ptes. The swap pte would refer to the old page from
which the SwapCache bit was cleared. This is dependent on remove_from_swap
always functioning properly which happened pretty late in the 2.6.16
cycle.
Here is the description from V9 of the direct migration patchset which
introduced the 3 checks for PageSwapCache():
Check for PageSwapCache after looking up and locking a swap page.
The page migration code may change a swap pte to point to a different page
under lock_page().
If that happens then the vm must retry the lookup operation in the swap
space to find the correct page number. There are a couple of locations
in the VM where a lock_page() is done on a swap page. In these locations
we need to check afterwards if the page was migrated. If the page was
migrated
then the old page that was looked up before was freed and no longer has
the
PageSwapCache bit set.
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Christoph Lameter <clameter@@sgi.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.