https://bugs.kde.org/show_bug.cgi?id=452802
Paul Floyd changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #19 from Paul Floyd ---
For the diffs, I see
1 scope problem
twice the following two
1 naming
1 static
1 paths + inlining
I haven't gone into it in detail. About half of the differences are reasonable.
I still want to keep this expected
https://bugs.kde.org/show_bug.cgi?id=452802
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=452802
Paul Floyd changed:
What|Removed |Added
Attachment #148662|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #16 from Paul Floyd ---
(In reply to Mark Wielaard from comment #15)
For macos I don't know if any of these changes are applicable so I wanted to
keep the old code if #if blocks.
I'll clean up unrelated changes and push them separately.
https://bugs.kde.org/show_bug.cgi?id=452802
Mark Wielaard changed:
What|Removed |Added
CC||m...@klomp.org
--- Comment #15 from Mark
https://bugs.kde.org/show_bug.cgi?id=452802
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #14 from Paul Floyd ---
On Fedora 34, git head and "./configure CC=clang CXX=clang++
LDFLAGS=-fuse-ld=lld" with thispatch the results look fairly similar to what I
get on FreeBSD.
I didn't get all of the problems that I had with FreeBSD
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #13 from Paul Floyd ---
On FreeBSD 13 amd64, OK with both clang and gcc.
On Linux Fedora 34 amd64 also OK.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #12 from Paul Floyd ---
Created attachment 148662
--> https://bugs.kde.org/attachment.cgi?id=148662=edit
Patch for reading debuginfo correctly with lld 9+
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #11 from Paul Floyd ---
Almost there.
none/tests/mmap_fcntl_bug is failing
mmap_fcntl_bug: Child got lock, we must have dropped it (TEST FAILED)
And this happens whether the client was built with GCC of clang.
It seems that the extra
https://bugs.kde.org/show_bug.cgi?id=452802
Paul Floyd changed:
What|Removed |Added
Platform|Other |Compiled Sources
OS|Other
https://bugs.kde.org/show_bug.cgi?id=452802
Paul Floyd changed:
What|Removed |Added
Version|unspecified |3.20 GIT
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #10 from Paul Floyd ---
OK, this is to do with how the ELF exe or shared lib gets loaded. There are 3
cases.
1. the tool itself, already loaded and we look at the maps and work backwards
to get NSegments and dinfo.
2. The client (and
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #9 from Paul Floyd ---
I've gone with plan A.
In ULong VG_(di_notify_mmap) I replaced the call to ML_(is_elf_object_file)
with a call to a new function ML_(check_elf_and_get_rw_loads) .
This is an ultra-stripped down version of
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #8 from Paul Floyd ---
No, not quite.
It seems like Valgrind loads the exe (and normally the interpreter, which is
does with VG_(load_ELF) and readelf. I think that these read the phdrs and
shdrs, and pre-allocates the NSegements. That
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #7 from Paul Floyd ---
After barking up the wrong tree for some time (merging RW PT_LOADs), I think
that I now see what I need to do.
1. ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
This is probably the trickier
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #6 from Paul Floyd ---
I see a similar problem on Linux (llvm 12,0,1 on Fedora 34).
memcheck/tests/varinfo5 fails, mainly failing to read debuginfo form the .so to
get variable names.
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #4 from Paul Floyd ---
Needs more work. Maybe store 'offset' and a 'mergeoffset'
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #5 from Paul Floyd ---
Or more precisely 'offset' and 'merge_remainder' or something like that.
where 'merge_remainder' would be
PGRNDDN(off - PGRNDDN(off) + prevoff - PGRNDDN(prefoff))
(unless there is a page remainder macro).
This
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #3 from Paul Floyd ---
What I'm going to try is, in elf.c
for (i = 0; i < e->e.e_phnum; i++) {
ESZ(Phdr) *ph = >p[i];
ESZ(Phdr) *phprev = NULL;
ESZ(Addr) addr, bss, brkaddr;
ESZ(Off) off;
ESZ(Word) filesz;
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #2 from Paul Floyd ---
I have a theory, not really based on a firm understanding or thorough
debugging.
For this
res = VG_(am_mmap_file_fixed_client)(
VG_PGROUNDDN(addr),
https://bugs.kde.org/show_bug.cgi?id=452802
--- Comment #1 from Paul Floyd ---
Looking at the segment handling code, maybe_merge_nsegments should be doing
this.
readelf -e says
Program Headers:
TypeOffset VirtAddr
PhysAddr
https://bugs.kde.org/show_bug.cgi?id=452802
Paul Floyd changed:
What|Removed |Added
Assignee|jsew...@acm.org |pjfl...@wanadoo.fr
--
You are receiving this
24 matches
Mail list logo
