On Fri, 2019-06-28 at 23:07 +0200, Mark Wielaard wrote:
> To print eh human readable description of the ELF e_machine header field
> we used the ebl name. But this is not set for most EM constants. Introduce
> a new function dwelf_elf_e_machine_string that does work for all known
> EM
_RCE, not EM_CSKY? Is that deliberate?
Thanks,
Mark
chine != EM_ARM)))
+ || ehdr->e_machine != EM_ARM)
+ && (shdr->sh_type != SHT_CSKY_ATTRIBUTES
+ || ehdr->e_machine != EM_CSKY)))
continue;
printf (gettext ("\
And then hook check_object_attribute to display any CSKY specific
attribute names/values.
Cheers,
Mark
On Thu, 2019-07-11 at 11:11 +0800, Mao Han wrote:
> On Wed, Jul 10, 2019 at 11:33:23PM +0200, Mark Wielaard wrote:
> > On Mon, 2019-06-03 at 16:16 +0800, Mao Han wrote:
> > > test binary:
> > > https://github.com/c-sky/test-result/blob/master/elfutils/divzero
> >
Y ELF core files?
If you have any other way to generate a core file (maybe gdb/gcore can
do it?) that would be really helpful.
Thanks,
Mark
have the above commit/fix in your tree and see if
it passes then.
Thanks,
Mark
(TLS_TPOFF32, EXEC|DYN)
The TLS variants aren't yet listed in the CPU ABI doc, but are in
elf.h, so I assume they are OK.
We can list the v1 variants also, their numbers don't overlap.
Just checking it is done deliberately. If they can never occur in v2
ELF binaries I would leave them out.
Cheers,
Mark
h the csky and elfclassify tool enough. If not, we'll still do a
release next week, just without those additions. The last 4 months saw
enough improvements to do a new release. And we'll do another in 3 or 4
months anyway, so if anything misses this release it will go into the
next.
Cheers,
Mark
On Thu, 2019-07-11 at 11:19 +0800, Mao Han wrote:
> On Thu, Jul 11, 2019 at 12:11:17AM +0200, Mark Wielaard wrote:
> > As far as I can see this is like a SHT_GNU_ATTRIBUTES or
> > SHT_ARM_ATTRIBUTES section. If so, you will also want something
> > like:
> >
> >
On Sat, 2019-07-13 at 00:36 +0200, Mark Wielaard wrote:
> In another thread I said I would like to do a release end of this week
> with the csky backend and the elfclassify tool integrated. But I didn't
> make enough time for reviews, so that moves to next week. Sorry.
>
>
at present.
OK. It is fine as is then. Just wanted to make sure it was as intended.
> > On Thu, 2019-07-11 at 11:19 +0800, Mao Han wrote:
> > > On Thu, Jul 11, 2019 at 12:11:17AM +0200, Mark Wielaard wrote:
> > > > As far as I can see this is like a SHT_GNU_ATTRIBUTES o
changelog to corresponding entries
> - correct core dump registers size
> - remove unused fpu DWARF register
>
> Changes since v3:
> - add testfilecsky.bz2 and hello_csky.ko.bz2
> - add csky_check_object_attribute
>
> Mao Han (1):
> Add backend support for C-SKY
The new patch looks really good. Thanks. The addition of the testcases
really helps showing things look good. I can make that one small fix
s/gnu/csky/ in csky_attrs.c if you agree that is what was intended.
Then I'll push it to master.
And after the next release we can add some more testcases and handle to
register mappings more correctly.
Thanks,
Mark
ded.
> > Then I'll push it to master.
>
> Yes, please. Thanks for your review and help improveing the patch.
Pushed (with one small tweak, added the new test bz2 files to
EXTRA_DIST so they will also be in any release tar balls).
Thanks,
Mark
e.wildebeest.org/git/user/mjw/elfutils/log/?h=elfclassify
Please let me know if any of this looks bad or unusual.
I'll write some testcases.
Thanks,
Mark
diff --git a/src/Makefile.am b/src/Makefile.am
index 2b1c0dcb..69ac4dbe 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@
Hi,
Some answers to this older discussion to explain some of my recent
commits suggested for elfclassify.
On Tue, 2019-04-16 at 13:38 +0200, Florian Weimer wrote:
> * Mark Wielaard:
> > --elf PATH return 0 whenever the file can be opened and a minimal ELF
> > header can be read (
ant to identify such "libraries" as
programs. But in general it looks like --shared and --executable come
up with the correct classification.
The only two examples I could find were the glibc and Qt binaries
which have "dual use" library/executables. And I believe --shared
corrrectly identifies them as primarily shared libraries.
Cheers,
Mark
On Fri, Jul 19, 2019 at 02:47:09PM +0200, Mark Wielaard wrote:
> The individual commits can be found here:
> https://code.wildebeest.org/git/user/mjw/elfutils/log/?h=elfclassify
>
> Please let me know if any of this looks bad or unusual.
>
> I'll write some testcases.
And
On Sat, Jul 20, 2019 at 01:57:27AM +0300, Dmitry V. Levin wrote:
> On Fri, Jul 19, 2019 at 11:36:53PM +0200, Mark Wielaard wrote:
> > > If the ELF type is ET_DYN and the object is not marked as DF_1_PIE,
> > > could we come up with a more reliable heuristics than DT_SONAME
> --library?
This patch implements this and updates the --help text to better explain
the differenes between --loadable, --shared/--executable and
--program/--library.
Does this look reasonable?
Cheers,
Mark
---
src/elfclassify.c | 59 +++
1 f
per's
Certificate of Origin as expressed in our CONTRIBUTING file.
Thanks,
Mark
>From 990f0cf28d2bc50837172831f7b3c2bafe272265 Mon Sep 17 00:00:00 2001
From: Florian Weimer
Date: Thu, 11 Apr 2019 18:07:20 +0200
Subject: [PATCH] elfclassify: New tool to analyze ELF objects.
Usage: eu-elfcla
On Sat, Jul 27, 2019 at 02:04:48AM +0300, Dmitry V. Levin wrote:
> On Sat, Jul 20, 2019 at 11:51:16PM +0200, Mark Wielaard wrote:
> > On Sat, Jul 20, 2019 at 01:57:27AM +0300, Dmitry V. Levin wrote:
> [...]
> > > btw, I think it would be appropriate to move the has_dynamic c
On Mon, Jul 29, 2019 at 10:43:56AM +0200, Florian Weimer wrote:
> * Mark Wielaard:
>
> > + if (elf == NULL)
> > +{
> > + /* This likely means it just isn't an ELF file, probably not a
> > +real issue, but warn if verbose reporting. */
> >
On Mon, Jul 29, 2019 at 11:16:31AM +0200, Florian Weimer wrote:
> * Mark Wielaard:
>
> > +/* Called to process standard input if flag_stdin is not no_stdin. */
> > +static void
> > +process_stdin (int *status)
> > +{
> > + char delim;
> > + if (fla
On Mon, Jul 29, 2019 at 11:22:13AM +0200, Florian Weimer wrote:
> * Mark Wielaard:
>
> > Signed-off-by: Mark Wielaard
>
> Does elfutils use DCO? Then yoy have my signoff as well:
>
> Signed-off-by: Florian Weimer
Thanks. Yes, elfutils uses a Developer Certificat
ery nice find!
Using strace or valgrind --track-fds=yes on eu-stack --core it is easy
to see what is going wrong. Luckily your fix is easy and obviously
correct.
Installed on master.
Thanks,
Mark
On Mon, 2019-07-29 at 16:24 +0200, Mark Wielaard wrote:
> On Mon, Jul 29, 2019 at 10:43:56AM +0200, Florian Weimer wrote:
> > * Mark Wielaard:
> >
> > > + if (elf == NULL)
> > > +{
> > > + /* This likely means it just isn't an ELF file,
On Mon, Aug 12, 2019 at 10:14:20AM +0200, Florian Weimer wrote:
> * Mark Wielaard:
>
> > What do you think about this change to dwelf_elf_begin?
> > The change would make it possible to detect real errors in the
> > elfclassify code, whether elf_begin or dwelf_elf_begin w
t. But now I wonder why ret == 0 can ever happen. Maybe on
> OpenVMS, which doesn't use in-band signaling for line terminators?
I also couldn't create a situation where ret == 0.
But I still included the change because it feels more robust.
Thanks,
Mark
Hi,
With the dwelf_elf_begin fix now committed I intend to commit the
elfclassify tool as attached. It now treats a NULL return from
[dwelf_]elf_begin always as error. It has the new --library
classification and various fixes that were pointed out during the
review.
Cheers,
Mark>F
On Mon, Jul 15, 2019 at 12:17:36PM +0200, Mark Wielaard wrote:
> On Sat, 2019-07-13 at 00:36 +0200, Mark Wielaard wrote:
> > In another thread I said I would like to do a release end of this week
> > with the csky backend and the elfclassify tool integrated. But I didn't
>
file
an ELF handle of type ELF_K_NONE is returned.
backends: Add support for C-SKY.
* GIT SHORTLOG *
Florian Weimer (1):
elfclassify: New tool to analyze ELF objects.
Mao Han (2):
libelf: Sync elf.h from glibc
Add backend support for C-SKY
Mark Wielaard (42):
libelf: Handle
d eu-elfclassify there for consistency.
Yes, we certainly should have it in the (example) spec file.
Pushed to master.
Thanks,
Mark
0702.819906] [<03ffa8104516>] 0x3ffa8104516
The last few builds on lfedora1 also took way longer than usual.
https://builder.wildebeest.org/buildbot/#/builders/10
It used to take 30~40 minutes, but now it takes 3~4 hours...
I wonder if something is wrong with the s390x build host.
Thanks,
Mark
There are multiple sections that can contain ELF Notes. It is sometimes
nice to just list the notes from a specific section.
-n, --notes[=SECTION] Display the ELF notes
Signed-off-by: Mark Wielaard
---
src/ChangeLog | 7 +++
src/readelf.c | 13 -
2 files changed, 19
ieve there are some
(accidental) incompatibilities anyway.
Cheers,
Mark
roken locking
and simply making it the default.
> - Another implementation of #2 above might use dynamic TLS
>(pthread_key_*),
>we chose this implementation to reduce the overall complexity.
Are there any other trade-offs?
Thanks,
Mark
ble-valgrind-annotations
> + * configure.ac: Add new --with-valgrind (headers only)
> +
> 2019-08-13 Mark Wielaard
>
> * configure.ac: Set version to 0.177.
> diff --git a/configure.ac b/configure.ac
> index c443fa3b..c5406b44 100644
> --- a/configure.ac
> +++ b/configu
On Wed, 2019-08-21 at 23:50 +0200, Mark Wielaard wrote:
> On Fri, 2019-08-16 at 14:24 -0500, Jonathon Anderson wrote:
> > @@ -668,6 +697,7 @@ AC_MSG_NOTICE([
> >OTHER FEATURES
> > Deterministic archives by default :
> > ${default_ar_deterministic}
>
commits to show the origins of
each patch. Please read:
https://sourceware.org/git/?p=elfutils.git;a=blob_plain;f=CONTRIBUTING;hb=HEAD
And add one if you agree.
Thanks,
Mark
Hi,
On Wed, 2019-08-21 at 09:08 -0500, Jonathon Anderson wrote:
> On Wed, Aug 21, 2019 at 6:16 AM, Mark Wielaard
> wrote:On Fri, 2019-08-16 at 14:24 -0500, Jonathon Anderson wrote:
> > > For parallel applications that need the information in the DIEs, the
> > > Dwarf
On Wed, 2019-08-21 at 09:20 -0500, Jonathon Anderson wrote:
> First message failed to send, hopefully this one works...
Just for the record, the mailinglist did reject HTML
messages/attachments. It should have been changed now to simply strip
the HTML.
Cheers,
Mark
nce to a
repo/branch from which to pull a patch (or use a git request-pull
message).
Thanks,
Mark
lloc (dbg->mem_default_size);
> + result->size = dbg->mem_default_size
> + - offsetof (struct libdw_memblock, mem);
> + result->remaining = result->size;
> + result->prev = NULL;
> + dbg->mem_tails[thread_id] = result;
> +}
> + pthread_rwlock_unlock (&dbg->mem_rwl);
> + return result;
Here the lock is dropped and result points into dbg->mem_tails
which means it cannot be used because the realloc above might
make it invalid.
> +}
>
> void *
> __libdw_allocate (Dwarf *dbg, size_t minsize, size_t align)
> @@ -52,8 +116,10 @@ __libdw_allocate (Dwarf *dbg, size_t minsize, size_t
> align)
> newp->size = size - offsetof (struct libdw_memblock, mem);
> newp->remaining = (uintptr_t) newp + size - (result + minsize);
>
> - newp->prev = dbg->mem_tail;
> - dbg->mem_tail = newp;
> + pthread_rwlock_rdlock (&dbg->mem_rwl);
> + newp->prev = dbg->mem_tails[thread_id];
> + dbg->mem_tails[thread_id] = newp;
> + pthread_rwlock_unlock (&dbg->mem_rwl);
>
> return (void *) result;
> }
Cheers,
Mark
Hi Jonathon,
On Sat, 2019-08-24 at 20:10 -0500, Jonathon Anderson wrote:
> On Sat, Aug 24, 2019 at 6:24 PM, Mark Wielaard wrote:
> > But what if realloc moves the block?
> > Then all dbg->mem_tails[thread_id] pointers become invalid.
> > And this function drops the
Hi,
On Wed, 2019-08-21 at 12:32 +0200, Mark Wielaard wrote:
> There are multiple sections that can contain ELF Notes. It is sometimes
> nice to just list the notes from a specific section.
>
> -n, --notes[=SECTION] Display the ELF notes
Pushed to master.
block it would get a random value, since
those are malloced. In your patch the memblocks are always malloced,
and so the bug shows up immediately.
Lets just cherry-pick this fixup since it is a good fixup to have.
Does the attached look correct?
Thanks,
Mark
From 4bcc641d362de4236ae8f0f5bc933c
Hi Omar,
On Tue, 2019-07-09 at 12:25 -0700, Omar Sandoval wrote:
> On Tue, Jul 09, 2019 at 09:14:03PM +0200, Mark Wielaard wrote:
> > Then after the release, somewhere next week, we'll apply your patches
> > first and can then deal with any fallout and followups. I am thinkin
ress-offsets
(which seem unique to eu-readelf) are not documented yet.
But it is all we have, so for now I committed it.
Thanks,
Mark
--- eu-readelf.1 2019-08-27 13:12:38.487568453 +0200
+++ doc/readelf.1 2019-08-27 12:08:31.930097151 +0200
@@ -158,8 +158,8 @@
[\fB\-c\fR|\fB\-\-ar
The readelf code did parse section numbers, but then failed to actually
dump the section found. Fixed by actually calling the dump function
(either the hex or string variant). Add testcase for readelf -x num.
Signed-off-by: Mark Wielaard
---
src/ChangeLog | 5 +
src/readelf.c
Now that we have manpages lets also package them.
Signed-off-by: Mark Wielaard
---
config/ChangeLog| 5 +
config/elfutils.spec.in | 2 ++
2 files changed, 7 insertions(+)
diff --git a/config/ChangeLog b/config/ChangeLog
index 12a141b2..f4d80224 100644
--- a/config/ChangeLog
+++ b
On Wed, 2019-08-28 at 00:34 +0200, Mark Wielaard wrote:
> Now that we have manpages lets also package them.
>
> +2019-08-28 Mark Wielaard
> +
> + * elfutils.spec.in (%files): Add man1/eu-*.1*.
> + (%files libelf-devel): Add man3/elf_*.3*.
That clearly isn't eno
On Mon, 2019-08-26 at 10:58 -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> The tool was just added, but it's missing the ignore entry.
Thanks, applied to master.
On Mon, 2019-08-26 at 10:51 -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> gen_SOURCES is assigned to libebl_a_SOURCES and never used again. Get
> rid of it.
Thanks for the cleanup. Applied to master.
On Mon, 2019-08-26 at 10:51 -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> In preparation for combining the libebl backend modules,
> combine all of the libcpu backends into libcpu.a.
Another nice cleanup. Pushed to master.
Thanks,
Mark
So, make libcpu.a and
> libebl.a non-PIC and add libcpu_pic.a and libebl_pic.a.
Thanks, and thanks for the subtle cleanups of the headers and mostly-
clean files. I tested against --enable-gcov, which is the only place we
actually use BUILD_STATIC, and that looks good too.
Pushed to master,
Mark
uildbot URL: https://builder.wildebeest.org/buildbot/
That is an --enable-sanitize-undefined. I am not entirely clear on why
it only fails when linming with -fsanitize=undefined. But libasm.so
should also be linked with libebl_pic.a.
Which is what the attached fix does.
ly be eliminated (both the backends and libebl have some
functions with zero coverage).
Thanks,
Mark
From: Jonathon Anderson
Uses the stdatomic.h provided by FreeBSD when GCC doesn't (ie. GCC < 4.9)
Signed-off-by: Jonathon Anderson
Signed-off-by: Srđan Milaković
---
configure.ac | 12 ++
lib/ChangeLog| 6 +
lib/Makefile.am | 3 +-
lib/atomics.h| 37
li
gt; size hash table.
[PATCH 1/3] Add some supporting framework for C11-style atomics.
[PATCH 2/3] libdw: Rewrite the memory handler to be thread-safe.
[PATCH 3/3] lib + libdw: Add and use a concurrent version of the
Cheers,
Mark
From: Jonathon Anderson
Signed-off-by: Jonathon Anderson
---
libdw/ChangeLog | 8 ++
libdw/Makefile.am | 4 +--
libdw/dwarf_begin_elf.c | 12 -
libdw/dwarf_end.c | 7 ++---
libdw/libdwP.h | 59 ++---
libdw/libdw_all
From: Srđan Milaković
Signed-off-by: Srđan Milaković
---
lib/ChangeLog| 5 +
lib/Makefile.am | 4 +-
lib/dynamicsizehash_concurrent.c | 522 +++
lib/dynamicsizehash_concurrent.h | 118 +++
libdw/ChangeLog
of the self test files with smaller
executables/libraries as attached. Hopefully that will reduce the make
check runtime under valgrind so builder don't time out.
Cheers,
Mark
From bb106065dc6962fabf1c163f18c932650dac6580 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Thu, 29 Aug 2019
On Thu, Aug 29, 2019 at 04:23:24PM +0200, Mark Wielaard wrote:
> I am replacing some of the self test files with smaller
> executables/libraries as attached. Hopefully that will reduce the make
> check runtime under valgrind so builder don't time out.
That was interesting. It did
On Tue, Aug 27, 2019 at 04:12:35PM +0200, Mark Wielaard wrote:
> The readelf code did parse section numbers, but then failed to actually
> dump the section found. Fixed by actually calling the dump function
> (either the hex or string variant). Add testcase for readelf -x num.
Pushed to master.
On Wed, Aug 28, 2019 at 12:32:17PM +0200, Mark Wielaard wrote:
> On Wed, 2019-08-28 at 00:34 +0200, Mark Wielaard wrote:
> > Now that we have manpages lets also package them.
> >
> > +2019-08-28 Mark Wielaard
> > +
> > + * elfutils.spec.in (%files): Add man
All archive members from libebl.a are now in libdw.a. We don't generate
separate backend shared libraries anymore. So remove them from the
elfutils.spec file.
Signed-off-by: Mark Wielaard
---
config/ChangeLog| 7 +++
config/elfutils.spec.in | 10 ++
libebl/Chan
testcase to show --symbols=.dynsym and
--dyn-sym produce the same output.
Signed-off-by: Mark Wielaard
---
doc/ChangeLog | 5 +
doc/readelf.1 | 9 +++--
src/ChangeLog | 8
src/readelf.c | 14 +-
tests/ChangeLog| 4
On Tue, 2019-09-03 at 09:44 +0200, Florian Weimer wrote:
> * Mark Wielaard:
>
> > It is already possible to select the symbol table to print by name,
> > using --symbols=SECTION. This allows printing the dynamic symbol table
> > with --symbols=.dynsym. binutils readelf
rest of the
code) fixes this. This is the second attached patch.
Note that the s390x builder was just taken offline for repairs. It
should come back online later this weekend. So it might take a bit for
the builder to be completely green again.
Cheers,
Mark>From 1ee98b6c28fbe9ab532ef947cfe46e8335
was intended.
Please do add a Signed-off-by to your commits in the future.
See the CONTRIBUTING file for more details.
Thanks,
Mark
On Thu, 2019-08-29 at 23:43 +0200, Mark Wielaard wrote:
> All archive members from libebl.a are now in libdw.a. We don't generate
> separate backend shared libraries anymore. So remove them from the
> elfutils.spec file.
Pushed to master.
On Tue, 2019-09-03 at 00:10 +0200, Mark Wielaard wrote:
> It is already possible to select the symbol table to print by name,
> using --symbols=SECTION. This allows printing the dynamic symbol table
> with --symbols=.dynsym. binutils readelf allows printing just the
> dynamic symbol t
interface you are probably looking for
dwarf_next_lines () and dwarf_linesrc (), you can then use the
different dwarf_line* () functions to get at the attributes.
Cheers,
Mark
get some
information about function or some syntactical scopes from the DIE
tree. Which you can get with dwarf_ranges (). Which might or might not
be what you are looking for?
Cheers,
Mark
itional debugger is a lot of work. Although people have
done something like that, see https://sourceware.org/systemtap and
https://drgn.readthedocs.io.
Cheers,
Mark
On Mon, Sep 30, 2019 at 02:39:50PM +0300, Dmitry V. Levin wrote:
> When an input file cannot be opened, include its name
> into the error diagnostics.
Looks very sensible. Pushed to master.
Thanks,
Mark
Hi,
Finally back to this patch series.
On Thu, 2019-08-29 at 15:16 +0200, Mark Wielaard wrote:
> diff --git a/libdw/dwarf_end.c b/libdw/dwarf_end.c
> index 29795c10..fc573cb3 100644
> --- a/libdw/dwarf_end.c
> +++ b/libdw/dwarf_end.c
> @@ -94,14 +94,15 @@ dwarf_end (Dwarf *dwarf)
Hi,
On Mon, 2019-10-21 at 11:28 -0500, Jonathon Anderson wrote:
> On Mon, Oct 21, 2019 at 18:13, Mark Wielaard wrote:
> > Does that look reasonable?
>
> It does, although I would prefer:
>
> diff --git a/libdw/dwarf_end.c b/libdw/dwarf_end.c
> index 9ca17212..6da9e
On Thu, 2019-08-29 at 15:16 +0200, Mark Wielaard wrote:
> From: Jonathon Anderson
>
> Uses the stdatomic.h provided by FreeBSD when GCC doesn't (ie. GCC <
> 4.9)
>
> Signed-off-by: Jonathon Anderson
> Signed-off-by: Srđan Milaković
>
> diff --git a/li
Hi,
On Mon, 2019-10-21 at 20:00 +0200, Mark Wielaard wrote:
> I think we cannot use the atomic_load () function, but have to use
> atomic_load_explicit. So it would become:
>
> diff --git a/libdw/dwarf_end.c b/libdw/dwarf_end.c
> index fc573cb3..a2e94436 100644
> --- a/libdw/d
k and one num_blocks field?
I do think the code itself is good. The above are mostly just nitpicks.
But if you could reply and give your thoughts on them that would be
appreciated.
Thanks,
Mark
diff --git a/lib/dynamicsizehash_concurrent.c b/lib/dynamicsizehash_concurrent.c
index d645b143..5fa38
ceed such a low limit.
I'll see if I can create a case where that is a problem. Then we can
see how to adjust things to use less pthread_keys. Is there a different
pattern we can use?
Thanks,
Mark
looks like the s390x buildbot worker was just overloaded and timed
out during a compile job. The next build did succeed and everything
looks green.
Cheers,
Mark
hen parsing all of the linux kernel debug data we are
talking about ~535000 allocations, a bit less than half (~233000) are
of the same small size, 24bytes.
> On Sat, Oct 26, 2019 at 18:14, Florian Weimer wrote:
> > * Mark Wielaard:
> >
> > > I'll see if I can cre
ll not a bump-pointer
> allocator, but at least there are no atomics on that path.
Since which version of glibc is there a thread-local fast path?
We don't need a bump-pointer allocator, but we do need something to
store lots of small object allocated over time together, so we can
easily dispose of them when done. The storage size only has to grow.
Thanks,
Mark
On Fri, 2019-10-25 at 23:11 -0500, Jonathon Anderson wrote:
> On Sat, Oct 26, 2019 at 01:50, Mark Wielaard wrote:
> > For example I am not sure I can proof that in resize_worker() this
> > always holds: assert(GET_STATE(resize_state) != NO_RESIZING);
> > In genera
On Sat, 2019-10-26 at 19:56 -0500, Jonathon Anderson wrote:
> On Sun, Oct 27, 2019 at 00:50, Mark Wielaard wrote:
> >
> > I see that getconf PTHREAD_KEYS_MAX gives 1024 on my machine.
> > Is this tunable in any way?
>
> From what I can tell, no. A quick google sear
to 64 bytes easily (moving bits to the master
> thread's stack), but that's the limit with this design.
Although I would like to see that if you have time, I am not that
concerned. And I think the pthread_key limit issue is more important to
resolve.
Thanks,
Mark
On Sun, 2019-10-27 at 17:13 +0100, Mark Wielaard wrote:
> On Fri, 2019-10-25 at 23:11 -0500, Jonathon Anderson wrote:
> > A quick grep -r shows that ITERATE and REVERSE are used for the
> > asm_symbol_tab. If iteration and insertion are not concurrent we can
> > eas
usage from dwfl_thread_getframes. So doesn't it need to
do its own cleanup?
Thanks,
Mark
s what their caller wants. So
yes, this makes sense. Added that extra sentence to the commit message
and pushed to master.
Thanks,
Mark
epo I could get them from?
Thanks,
Mark
From: Jonathon Anderson
Pthread's thread-local variables are highly limited, which makes
it difficult to use many Dwarfs. This replaces that with a
less efficient (or elegant) but more robust method.
Signed-off-by: Jonathon Anderson
---
lib/atomics.h | 2 ++
libdw/ChangeLog
From: Jonathon Anderson
Signed-off-by: Jonathon Anderson
---
ChangeLog| 5 +
configure.ac | 30 ++
2 files changed, 35 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index 911cf354..433a5f3c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2019-08-
ound is always the initial frame, so there's no need to
> update it as we unwind the stack. Let's set it to NULL after we do the
> initial setup. This simplifies the next change.
Very nice cleanup. Pushed to master.
Thanks,
Mark
ou thought about just calling debuginfod-find from the libdwfl
code? Or is execing from a library really just a no-no?
Thanks,
Mark
imple to get wrong causing leaks and locking up
processes/threads.
Also, if we would adopt dwfl_attach_thread then I think it should take
a Dwfl_Thread object not a pid/tid as argument.
Could you provide some examples where this new interface/style is
beneficial?
Thanks,
Mark
't
done for the initial frame. Also it isn't clear how to propagate any
errors when NULL is returned. Maybe dwfl_frame_dwarf_frame () should
check first to see if frame is NULL and then call lookup the CFI and
call dwarf_cfi_addrframe if not?
Thanks,
Mark
the interface.
Having some examples/testcases would also show how/where to get the
DWARF expressions to use with this new function.
Thanks,
Mark
carefully with signals.) Another reason
> for calling directly is avoidance of a race condition, wherein two
> debuginfod-client processes run at the same time, and one cleans the
> cache right under the foot of the other. From the C API, you're
> guaranteed to get a usable fd, even if the underlying file was
> unlinked while you were looking. An fd is all elfutils needs (which I
> love).
All good points. Ignore that I even mentioned calling exec directly
please :)
Thanks,
Mark
1401 - 1500 of 3433 matches
Mail list logo
