Re: [Crash-utility] submission about PaX linux support
----- Original Message -----
(2011/12/21 4:42), Dave Anderson wrote:
>
>
> ----- Original Message -----
>> Hello Dave,
>>
>> I would like to send proposed patch set which can support
>> PaX linux introduced at http://grsecurity.net/ over crash utility.
>>
>> In previous thread, you said that it is important for current implementation
>> not to be increased maintenance burden.
>>
>> Then, I tolerably think to consider about them in my merge work with
>> small modifications to current code as possible.
>> But the reality is, there are several undesirable impacts which
>> I made in this work.
>>
>> So could you please check and make a conclusion from this patch set?
>> (Detail about modification are written in each patch file.)
>>
>> Thanks,
>> Toshi
>
> Well, as I mentioned before, I'm not particular interested in
> supporting kernel features that are not merged upstream, and
> I'm afraid that I'd be starting down a slippery slope by accepting
> this patch.
Well, there are no happiness for upstream based users. I think so, too.
Honestly speaking, I feel to be got a large nuisance called PaX
and if possible, I want to extract this patch code from kernel.
I am going to maintain this detour works so that I won't make fear for you
because this mischief comes from product support issue which I use.
OK, I appreciate that.
...
All of ipv6 text sections are surrounded by sctp virtual address range.
I don't understand for detail and as far as my debugging,
gdb internal implementation didn't allocate or refer the ipv6's
LINETABLE() at GNU_GET_LINE_NUMBER operations.
I could not found out corresponding condition from gdb-7.3.1/
but maybe -readnow is simple and proper way for this problem.
I've tested and got the good result.
// sprintf(buf, "add-symbol-file %s 0x%lx",
sprintf(buf, "add-symbol-file %s 0x%lx
-readnow",
lm->mod_namelist, section_vaddr);
Interesting -- are you only seeing this behaviour with your PaX modules?
I ask because I saw similar behavior with module line numbers after the
gdb-7.3.1 merge, but was able to fix it in crash-6.0.1 by reading in the
second-stage debuginfo data whenever a specific line number was requested:
- Fix for the X86 kernel module line-number capability on some kernels.
It is unclear why only some kernel versions exhibit this problem,
but the newly-embedded gdb version 7.3.1 has changed behaviour such
that the addrmap arrays of module text address blocks may contain
the module text offset values instead of their loaded vmalloc
addresses, and so without the patch, there is no "match" for the
vmalloc address when searching for its line number information.
It is fixed by doing a preliminary symbol search before accessing
the line-number access routine.
(anderson(a)redhat.com)
with this patch:
+++ gdb-7.3.1/gdb/symtab.c
@@ -4951,10 +4951,17 @@ static void
gdb_get_line_number(struct gnu_request *req)
{
struct symtab_and_line sal;
+ struct symbol *sym;
CORE_ADDR pc;
#define LASTCHAR(s) (s[strlen(s)-1])
+ /*
+ * Prime the addrmap pump.
+ */
+ if (req->name)
+ sym = lookup_symbol(req->name, 0, VAR_DOMAIN, 0);
+
pc = req->addr;
sal = find_pc_line(pc, 0);
I could add the --readnow, but I'm thinking that it could cause a
significant amount of unnecessary debuginfo data to be read in and
stored.
Dave