Re: [PATCH] strip: Add --keep-section=SECTION and --remove-section=SECTION.
On Fri, 2017-07-14 at 12:24 -0700, Josh Stone wrote:
> On 07/14/2017 08:28 AM, Mark Wielaard wrote:
> > Adds two new output options:
> >
> > --keep-section=SECTION Keep the named section. SECTION is an extended
> > wildcard pattern. May be given more than once.
>
> I tried this with rust libraries (eu-strip --keep-section=.rustc), and
> it seems to work as desired. Thanks!
Thanks for testing.
Also make distcheck found a memory leak.
We used to only cleanup extra debug section data if there were symbol
table changes (then the original file would get the small/stripped
symbol table, but the debug file would get the full one). But now
another reason might be that we explicitly keep a section in the
original file, but it is also needed by another section that is moved
into the .debug file. For example we keep a string table that is also
needed by a removed symbol table.
So just always cleanup, not just when there were any symbol table
changes:
diff --git a/src/strip.c b/src/strip.c
index 3aad92e..4a35ea1 100644
--- a/src/strip.c
+++ b/src/strip.c
@@ -2267,14 +2267,14 @@ while computing checksum for debug information"));
if (shdr_info != NULL)
{
/* For some sections we might have created an table to map symbol
-table indices. */
- if (any_symtab_changes)
- for (cnt = 1; cnt <= shdridx; ++cnt)
- {
- free (shdr_info[cnt].newsymidx);
- if (shdr_info[cnt].debug_data != NULL)
- free (shdr_info[cnt].debug_data->d_buf);
- }
+table indices. Or we might kept (original) data around to put
+into the .debug file. */
+ for (cnt = 1; cnt <= shdridx; ++cnt)
+ {
+ free (shdr_info[cnt].newsymidx);
+ if (shdr_info[cnt].debug_data != NULL)
+ free (shdr_info[cnt].debug_data->d_buf);
+ }
/* Free data we allocated for the .gnu_debuglink section. */
free (debuglink_buf);
Added to the patch and pushed to master.
Cheers,
Mark
Re: File index given line (libdw)
On Mon, 2017-07-17 at 04:10 +, Sasha Da Rocha Pinheiro wrote: > [Resending cause it seems it didn't go] Probably because it had an HTML attachement. The mailinglist rejects emails with HTML. > You understood what I need when you said: > "So you want to keep a vector with filenames for a particular CU. And > then given Dwarf_Lines you want to associate each Dwarf_Line with a > particular filename from that vector." > > I agree with this "But currently that is an implementation detail. " > But I don't see why this would change. Deliberately sort the files > names so it doesn't match with the lines? I don't think so. But newer versions of DWARF could have a different way of sharing the source files or directory table between CUs. The issue is that the index from the Dwarf_Lines only makes sense if you know which CU the corresponding Dwarf_Files came from. So instead of providing the relationship between a Dwarf_Line and a Dwarf_File I rather would not depend on something indirect like the index into some Dwarf_Files table. If we do provide it then I think we should be explicit about what it is an index into. So maybe a function like: extern int * dwarf_line_files (Dwarf_Line *line, Dwarf_Files **files, size_t *idx); Where files and idx are returned in a way that make them useful with dwarf_filesrc. Would the above be helpful for your usecase? Cheers, Mark
Re: Dwarf_FDE (libdw)
On Mon, 2017-07-17 at 04:12 +, Sasha Da Rocha Pinheiro wrote:
> So how do you get the augmentation data out of a Dwarf_Frame?
You don't. You can only get the actual information relevant for the
frame through the augmentation data from the Dwarf_Frame. Is there
information missing you need?
> Or how do you "simulate" the two next functions as libdwarf do?
>
> dwarf_get_cie_augmentation_data
> dwarf_get_fde_augmentation_data
I don't know what those functions do precisely. But if you really want
to do something low level like get the CIE augmentation data you could
do it through dwarf_next_cfi and DWarf_CFI_entry:
Dwarf_CFI_Entry entry;
dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);
if (dwarf_cfi_cie_p (&entry))
{
cie_aug = entry.cie.augmentation_data;
cie_aug_size = entry.cie.augmentation_data_size;
}
else
{
Dwarf_Off off = entry.fde.CIE_pointer;
dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);
assert (dwarf_cfi_cie_p (&entry));
cie_aug = entry.cie.augmentation_data;
cie_aug_size = entry.cie.augmentation_data_size;
}
Plus some error handling. If you then also want to get the FDE
augmentation data it is a bit more work since you'll have to decode the
FDE data yourself (based on the CIE augmentation data you now got).
But instead of trying to extract the exact encoding of the low level
data it is probably better to see how we can make all the information
you need available through Dwarf_Frames.
Cheers,
Mark
[COMMITTED] backends: Swap sys/ptrace.h and asm/ptrace.h include order on s390.
glibc 2.26 changed the sys/ptrace.h header so that it cannot be included after asm/ptrace.h. We still need to include the kernel asm/ptrace.h for the ptrace_area definition. Including it after sys/ptrace.h works against both old and new glibc. Signed-off-by: Mark Wielaard --- backends/ChangeLog | 4 backends/s390_initreg.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/backends/ChangeLog b/backends/ChangeLog index c5f61e8..d628245 100644 --- a/backends/ChangeLog +++ b/backends/ChangeLog @@ -1,3 +1,7 @@ +2017-06-17 Mark Wielaard + + * s390_initreg.c: Swap sys/ptrace.h and asm/ptrace.h include order. + 2017-06-15 Andreas Schwab * ppc_symbol.c (ppc_machine_flag_check): New function. diff --git a/backends/s390_initreg.c b/backends/s390_initreg.c index 011305c..23bf8ed 100644 --- a/backends/s390_initreg.c +++ b/backends/s390_initreg.c @@ -34,8 +34,8 @@ #include #if defined(__s390__) && defined(__linux__) # include -# include # include +# include #endif #define BACKEND s390_ -- 1.8.3.1
Re: [COMMITTED] backends: Swap sys/ptrace.h and asm/ptrace.h include order on s390.
On Mon, Jul 17, 2017 at 05:44:54PM +0200, Mark Wielaard wrote: > glibc 2.26 changed the sys/ptrace.h header so that it cannot be included > after asm/ptrace.h. We still need to include the kernel asm/ptrace.h for > the ptrace_area definition. Including it after sys/ptrace.h works against > both old and new glibc. If it's a glibc regression, shouldn't it be fixed on glibc side before 2.26 is out? -- ldv signature.asc Description: PGP signature
Re: [COMMITTED] backends: Swap sys/ptrace.h and asm/ptrace.h include order on s390.
On Mon, 2017-07-17 at 19:29 +0300, Dmitry V. Levin wrote: > On Mon, Jul 17, 2017 at 05:44:54PM +0200, Mark Wielaard wrote: > > glibc 2.26 changed the sys/ptrace.h header so that it cannot be included > > after asm/ptrace.h. We still need to include the kernel asm/ptrace.h for > > the ptrace_area definition. Including it after sys/ptrace.h works against > > both old and new glibc. > > If it's a glibc regression, shouldn't it be fixed on glibc side before > 2.26 is out? I asked and it was done deliberately. See glibc 2.26 NEWS under Deprecated and removed features, and other changes affecting compatibility. For the functionality we needed it was always necessary to include the kernel asm/ptrace.h also (and it still is with 2.26) on s390. The only regression (for us) is that the order of the includes needs to be sys/ptrace.h first, then asm/ptrace.h. I double checked that the functionality needed still works (the run-backtrace-native.sh testcase works on both old s390 and s390x and new glibc s390x versions). Cheers, Mark
Re: Dwarf_FDE (libdw)
So you're saying that the augmentation data of a FDE is the augmentation data
of its CIE?
https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html
says differently.
The thing is I need to get catch blocks, and eh_frame is not exactly Dwarf
format. That's why I need FDE augmentation data also.
Libdw doesn't do this, am I correct?
From: Mark Wielaard
Sent: Monday, July 17, 2017 8:28:56 AM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_FDE (libdw)
On Mon, 2017-07-17 at 04:12 +, Sasha Da Rocha Pinheiro wrote:
> So how do you get the augmentation data out of a Dwarf_Frame?
You don't. You can only get the actual information relevant for the
frame through the augmentation data from the Dwarf_Frame. Is there
information missing you need?
> Or how do you "simulate" the two next functions as libdwarf do?
>
> dwarf_get_cie_augmentation_data
> dwarf_get_fde_augmentation_data
I don't know what those functions do precisely. But if you really want
to do something low level like get the CIE augmentation data you could
do it through dwarf_next_cfi and DWarf_CFI_entry:
Dwarf_CFI_Entry entry;
dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);
if (dwarf_cfi_cie_p (&entry))
{
cie_aug = entry.cie.augmentation_data;
cie_aug_size = entry.cie.augmentation_data_size;
}
else
{
Dwarf_Off off = entry.fde.CIE_pointer;
dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);
assert (dwarf_cfi_cie_p (&entry));
cie_aug = entry.cie.augmentation_data;
cie_aug_size = entry.cie.augmentation_data_size;
}
Plus some error handling. If you then also want to get the FDE
augmentation data it is a bit more work since you'll have to decode the
FDE data yourself (based on the CIE augmentation data you now got).
But instead of trying to extract the exact encoding of the low level
data it is probably better to see how we can make all the information
you need available through Dwarf_Frames.
Cheers,
Mark
Re: File index given line (libdw)
I understand your argument. Since I was doing: dwarf_getsrclines(&cuDIE, &lineBuffer, &lineCount) dwarf_getsrcfiles(&cuDIE, &files, &filecount) I knew they were related because I used the same DIE. But someone trying to use a function which returns only the index could be confusing about what Dwarf_Files it came from. But, with extern int * dwarf_line_files (Dwarf_Line *line, Dwarf_Files **files, size_t *idx); they would know what Dwarf_Files the line is related to. For me, though, I could pass NULL for files, since I already knew what it is. From: Mark Wielaard Sent: Monday, July 17, 2017 8:04 AM To: Sasha Da Rocha Pinheiro Cc: elfutils-devel@sourceware.org Subject: Re: File index given line (libdw) On Mon, 2017-07-17 at 04:10 +, Sasha Da Rocha Pinheiro wrote: > [Resending cause it seems it didn't go] Probably because it had an HTML attachement. The mailinglist rejects emails with HTML. > You understood what I need when you said: > "So you want to keep a vector with filenames for a particular CU. And > then given Dwarf_Lines you want to associate each Dwarf_Line with a > particular filename from that vector." > > I agree with this "But currently that is an implementation detail. " > But I don't see why this would change. Deliberately sort the files > names so it doesn't match with the lines? I don't think so. But newer versions of DWARF could have a different way of sharing the source files or directory table between CUs. The issue is that the index from the Dwarf_Lines only makes sense if you know which CU the corresponding Dwarf_Files came from. So instead of providing the relationship between a Dwarf_Line and a Dwarf_File I rather would not depend on something indirect like the index into some Dwarf_Files table. If we do provide it then I think we should be explicit about what it is an index into. So maybe a function like: extern int * dwarf_line_files (Dwarf_Line *line, Dwarf_Files **files, size_t *idx); Where files and idx are returned in a way that make them useful with dwarf_filesrc. Would the above be helpful for your usecase? Cheers, Mark
Re: Dwarf_FDE (libdw)
On Mon, Jul 17, 2017 at 05:16:00PM +, Sasha Da Rocha Pinheiro wrote: > So you're saying that the augmentation data of a FDE is the augmentation > data of its CIE? > https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html > says differently. If you need to read the low-level augmentation data from an FDE then you need to know whether it is there and how the FDE addresses are encoded. Which is encoded in the CIE augmentation data. > The thing is I need to get catch blocks, and eh_frame is not exactly > Dwarf format. That's why I need FDE augmentation data also. > Libdw doesn't do this, am I correct? libdw handles both .debug_frame and .eh_frame data. And you can use the Dwarf_Frames to unwind. I believe the only thing not directly exposed are the lsda and personality pointers. Is that the functionality that you need for "catch blocks"? Cheers, Mark
Re: Dwarf_FDE (libdw)
Yes, that's what I am trying to do right now. Try/catch blocks or exception handling is the right term I guess. From: Mark Wielaard Sent: Monday, July 17, 2017 12:48 PM To: Sasha Da Rocha Pinheiro Cc: elfutils-devel@sourceware.org Subject: Re: Dwarf_FDE (libdw) On Mon, Jul 17, 2017 at 05:16:00PM +, Sasha Da Rocha Pinheiro wrote: > So you're saying that the augmentation data of a FDE is the augmentation > data of its CIE? > > https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html Chapter 8. Exception Frames - Linux Foundation refspecs.linuxfoundation.org Chapter 8. Exception Frames. When using languages that support exceptions, such as C++, additional information must be provided to the runtime environment that ... > says differently. If you need to read the low-level augmentation data from an FDE then you need to know whether it is there and how the FDE addresses are encoded. Which is encoded in the CIE augmentation data. > The thing is I need to get catch blocks, and eh_frame is not exactly > Dwarf format. That's why I need FDE augmentation data also. > Libdw doesn't do this, am I correct? libdw handles both .debug_frame and .eh_frame data. And you can use the Dwarf_Frames to unwind. I believe the only thing not directly exposed are the lsda and personality pointers. Is that the functionality that you need for "catch blocks"? Cheers, Mark
Re: [COMMITTED] backends: Swap sys/ptrace.h and asm/ptrace.h include order on s390.
On Mon, Jul 17, 2017 at 06:41:47PM +0200, Mark Wielaard wrote: > On Mon, 2017-07-17 at 19:29 +0300, Dmitry V. Levin wrote: > > On Mon, Jul 17, 2017 at 05:44:54PM +0200, Mark Wielaard wrote: > > > glibc 2.26 changed the sys/ptrace.h header so that it cannot be included > > > after asm/ptrace.h. We still need to include the kernel asm/ptrace.h for > > > the ptrace_area definition. Including it after sys/ptrace.h works against > > > both old and new glibc. > > > > If it's a glibc regression, shouldn't it be fixed on glibc side before > > 2.26 is out? > > I asked and it was done deliberately. See glibc 2.26 NEWS under > Deprecated and removed features, and other changes affecting > compatibility. There are exactly two commits in glibc since 2.25 that changed sysdeps/unix/sysv/linux/s390/sys/ptrace.h: 3f67d1a7021ed3184830511636a0867faec730fe and b08a6a0dea63742313ed3d9577c1e2d83436b196. I reviewed and approved both of these commits assuming that they brought no regressions. If sys/ptrace.h from glibc 2.25 could be included before or after linux/ptrace.h, this shouldn't have changed in glibc 2.26. In other words, I think you've spotted a regression that I missed during b08a6a0dea63742313ed3d9577c1e2d83436b196 review and that has to be fixed in glibc before 2.26 is released. -- ldv signature.asc Description: PGP signature
Re: [COMMITTED] backends: Swap sys/ptrace.h and asm/ptrace.h include order on s390.
On Tue, Jul 18, 2017 at 01:24:46AM +0300, Dmitry V. Levin wrote: > I reviewed and approved both of these commits assuming that they brought > no regressions. If sys/ptrace.h from glibc 2.25 could be included before > or after linux/ptrace.h, this shouldn't have changed in glibc 2.26. > > In other words, I think you've spotted a regression that I missed during > b08a6a0dea63742313ed3d9577c1e2d83436b196 review and that has to be fixed > in glibc before 2.26 is released. Aha. So if you look at that patch you see that the same include pattern that got us in trouble was removed from sysdeps/s390/fpu/fesetenv.c and the new order is used in the newly added testcase sysdeps/unix/sysv/linux/s390/tst-ptrace-singleblock.c. On fedora s390x rawhide (which has a glibc 2.16 pre-release) including asm/ptrace.h before sys/ptrace.h will cause errors: https://kojipkgs.fedoraproject.org//work/tasks/4924/20574924/build.log Cheers, Mark
